Red Hat releases new OpenShift CLI developer tool | Hacker News Reader

Red Hat releases new OpenShift CLI developer tool

odo.dev

63 pointskihihosting51 comments

Open articleView on HN

If you're confused about what OpenShift is, we have coloring books and O'Reilly Books [0][1][2][3][4][5].

[0] https://raw.githubusercontent.com/fedoradesign/coloringbook-...

[1] https://docs.fedoraproject.org/en-US/fedora-silverblue/_atta...

[2] https://www.openshift.com/resources/ebooks/openshift-for-dev...

[3] https://www.openshift.com/learn/resources/ebooks

[4] https://www.openshift.com/resources/ebooks/deploying-to-open...

[5] https://www.openshift.com/resources/ebooks/devops-with-opens...

When is the Openshift Administrators book going to be released?

After they are done releasing new coloring books :)

Also potentially of interest to HN folks, Red Hat announced that their OpenShift Serverless product is generally available[0]. It's a Knative-based offering.

Disclosure: I work for VMware, a direct competitor in this space. Double disclosure: I am working on a Knative book. Triple disclosure: I am overly prone to pre-emptive disclosures.

[0] https://developers.redhat.com/blog/2020/04/30/serverless-app...

Disclosure: I work for Red Hat, a competitor to VMWare.

Your comment made my day, thank you :-)

Knative is super cool. I'm really glad to see it maturing so well into vendor offerings. Best of luck on your book!

How popular is OpenShift? Seems cool but have never heard of anyone actually using it.

I'm a huge fan, and it seems to be finding commercial success[1]. What it does well for me is preserve kubernetes concepts, but expose them in a way that's easier to manage from an admin standpoint. I learned kube through OpenShift - and was able to ramp up quickly enough to manage our internal application as an engineer.

[1] https://www.openshift.com/learn/success-stories/

its just kubernetes for redhat shops, so it will be roughly as popular as redhat enterprise and ibm services contracts. which is to say, probably billions in revenue, and yet no one on HN will touch it.

I would always consider it as an option because it is 100% open source and has all the primitives that are needed for the prevalent use case that is CI/CD. For instance built-in Jenkins, Imagestreams, Build Configs...

I had to deal with it past 2 years - it is extremely bloated, not very well thought out and anything that needs decently performing storage is screwed over by GlusterFS and now I guess Ceph. All in all you really want to carefully analyze which apps you want to put on it and how much benefit you are really getting out of it - because it isn't free in any sense of the word - licensing, maintenance, operations - you are adding a crap ton of complexity and giving developers more ways to shoot themselves in the foot.

[Wow, looks like we have OpenShift fans here. Still, I prefer leaving the f out of OpenShift like everyone who has actually worked on it trying to get complex apps running smoothly :)]

I want to get into OpenShift/OKD, but the distributed storage systems are quite frightening. There are plenty nightmare stories related to GlusterFS performance.

However, strange as it sounds, I'm looking to deploy a cluster on a single node, primarily for the Kubernetes API & ecosystem (so many tooling options).

What is your opinion on running K8s this way, and having only local RAID storage?

I have tried running OKD/OpenShift locally - even using the latest retake on it - Code Ready Containers. It is way too resource intensive for a single VM. That is before you start the prometheus/monitoring/alerting stuff or metrics server - at that point your single VM is good as dead.

You can just learn plain old K8S - get an Ubuntu VM and snap install microk8s. Add another vm as a node and it works well for most part and sans storage stuff (you can do NFS though) you can learn almost everything. After that catching up to OpenShift specifics is not that big of a deal - it's not all that different.

As mentioned, CodeReady Containers (CRC) is the easy button for a single node setup [0]. But it is heavy for a single node. Alternatives for labs and demos are learn.openshift.com [1] and the All-in-One VM blog [2]. Storage isn't too important in a single node setup unless you're looking for Metrics, Logging, and Monitoring to be turned on. You could use NFS if you have to. Just don't do that in Production, IMO.

[0] https://developers.redhat.com/blog/2019/09/05/red-hat-opensh...

[1] https://learn.openshift.com/

[2] https://www.openshift.com/blog/revamped-openshift-all-in-one...

This sounds like you want https://k3s.io, a kubernetes distribution specially made for single node and probably much simpler.

Disclaimer: I work for Red Hat Consulting where my day job is 100% OpenShift.

Storage isn't easy on OpenShift unless you're in one of the public clouds. Even then, there's caveats based on (mis-)use cases and what nots [0].

But on complexity, I think companies and developers do it to themselves by getting excited about 12 Factor Apps, Microservices, and Event Driven Architectures and not understanding what that all means. OpenShift & Kubernetes just make that easier to roll out. At the end of the day, OpenShift & Kubernetes is just ELBs, App Routers, scheduling, monitoring, and logging systems, some orchestration tools [1].

[0] https://docs.openshift.com/container-platform/4.3/scalabilit...

[1] http://uncontained.io/articles/openshift-ha-installation/

> OpenShift & Kubernetes is just ELBs, App Routers, scheduling, monitoring, and logging systems, some orchestration tools

True but consider this - there used to be people whose job it was to do most of that stuff and the app developers did not have to think about it for the most part. Kubernetes/OpenShift just moved all of the complexity on the developer's plate - and the mind numbing stuff that results from that is worthy of few articles. And to say most developers have no way to actually run this at their home and become familiar with the intricacies is even more asinine.

This isn't a OpenShift/K8s critique per se but the whole idea that you can somehow make all the complexity disappear by writing more software and more abstractions and then let the developers deal with all things that organizations failed to account for in the need for cheap and fast - it doesn't really work all that well.

> > OpenShift & Kubernetes is just ELBs, App Routers, scheduling, monitoring, and logging systems, some orchestration tools

> True but consider this - there used to be people whose job it was to do most of that stuff and the app developers did not have to think about it for the most part. Kubernetes/OpenShift just moved all of the complexity on the developer's plate - and the mind numbing stuff that results from that is worthy of few articles

Ignoring OpenShift, I don't think the comparison is quite that simple because it's leaving out all of the drawbacks from that traditional approach. Instead of writing a few lines of YAML you have to wrangle time and support from central IT, debugging is often a multi-party finger-pointing exercise with access limitations, and because you're talking about separate services and usually hardware changes and updates are hard because they need to be coordinated across multiple applications and teams.

That's not saying that there aren't legitimate areas for concern but I've seen fairly large amounts of developer time and downtime go into working around the limitations of that model (“<vendor> isn't compliant with this 15 year old RFC so we need to distribute forks of these 15 common tools for years until we can replace those $$$ appliances”).

I have thought a lot about this - I have and do work with a ton of apps across number of clients. The stated benefits of K8s/OpenShift are negated by the complexity that it brings for most of those apps - especially when they don't need or use any of the sophisticated features of K8S.

If your central IT knows anything about Automation / DevOps you should not be wrangling time with them at all. It is easy peasy to setup Jenkins/Ansible/Tower based self service workflow for automating deployment and other things. Most enterprise apps do not need autoscaling, or weird unsupported OSes and libraries - JVM and CLR solved that problem long time ago. If you did it right horizontal scaling any app server should be a piece of cake if and when that one time you actually need it.

If you do need specific OS versions/libs - just use plain old docker - that's much less complicated and at least serves a purpose.

The point I am trying to make is - very few classes of apps can benefit from the added complexity of K8S and you should carefully evaluate if your app can benefit from K8S specific features and your Developers/Ops team are ready to deal with the complexity they are signing up for.

Your experience is rather unlike mine — especially the belief that central IT departments are advanced devops practitioners.

Similarly, you're talking about a significant amount of work maintaining bespoke infrastructure duplicating what systems like Kubernetes, OpenShift, Nomad, etc. do but taking on the responsibility for integrating and supporting all of those disparate parts yourself, not to mention getting the policy, security, and operational go-ahead to do so.

“Easy peasy” does not match my experience with that approach but I'm glad it's working well for you.

Compared to maintaining a OCP cluster? Sure it is easy peasy - I can vouch for that having done both.

I have had a similar experience. It's certainly easily to grok the architecture when it's traditional and simple, but it's significantly more work when every app follows a different pattern (which tends to happen in bespoke infrastructure). I've done both and while I agree with the gp that k8s is overkill for a lot of apps, there's still a lot of value in having patterns and consistency. When you can go from Service A to Service B and know that it's laid out similar, the cognitive overhead of managing several or dozens of services goes way down.

Disclaimer: I work for Red Hat Consulting where my day job is 100% OpenShift.

You're probably using applications and systems which are hosted on OpenShift [0][1]. Second article says we have over 1100 customers which seems low, to me at least. We have OpenShift in a lot of places and you don't realize it (which is how we intend it). A subset of our customers can be found here [2].

I've personally worked on some really interesting systems and projects, successfully faced off against Black Friday, and reached some really interesting scales. But at the end of the day, OpenShift is a Kubernetes distribution [3] with an opinionated install story, an opinionated AppDev story, and the ability to be deployed on-prem, in the public & private clouds, and on VMs or baremetal. The try it on your laptop method can be found here, branded CodeReady Containers [4]. If you want to just play with an already running system, try learn.openshift.com [5].

[0] https://www.zdnet.com/article/ibm-paid-34b-for-this-where-re...

[1] https://technology.informa.com/617145/red-hats-container-sof...

[2] https://www.openshift.com/learn/success-stories/

[3] https://github.com/openshift/okd

[4] https://developers.redhat.com/blog/2019/09/05/red-hat-opensh...

[5] https://learn.openshift.com/

I work for a financial institution using openshift in cloud. Learning it now.

We tackle sepsis with OpenShift across our 180ish hospitals.

https://youtu.be/ZWMhZ83AHvY

I work almost exclusively with openshift- it's very popular for enterprise stuff. We've got a lot of clients in banking and insurance and those sorts of industries- where you need your technology to scale but you're not really a technology company.

We use it at my place if work, for some things. To be honest it's hit and miss whether our clients do - I'd say about 40% do.

I was pretty surprised to see our latest client uses it. I won't name any names but they're a HUGE teleco in Europe and operate in many countries.

Looks like it's growing in popularity.

Existing tools such as oc are more operations-focused and require a deep understanding of Kubernetes and OpenShift concepts

oc and kubectl commands are interchangable for the most part. This will lock you down to openshift.

Check the SHAs. They're actually the same binary. :D

On a properly installed system with the `openshift-clients` or `atomic-openshift-utils` rpms installed, `oc` and `kubectl` will have the same SHAs.

I think the "this" in his sentence is odo. AFAIK, that does require openshift.

Prediction: It's only a matter of time they come up with a monitoring suite named ODOMETER !

Hahaha. I don't think so. We have a built-in monitoring stack of sorts based on Prometheus and Grafana. There's lots of other partners that do monitoring well too.

I have not tried to install/work with Openshift recently. If Redhat can take the fast moving target that is Kubernetes, add its weight on it, provide excellent user focused documentation, And “stable”ize it for non big scale companies to use, that’ll be great.

Although, it is only useful if they are same/

I work in retail banking. Openshift is very common for new projects these days on private and hybrid cloud deployments. So common that a client of mine recently described Openshift as ‘legacy’. Very silly comment but it does say a lot about how widely used it is in large enterprises.

Is it possible to run the open source okd variant reliably yet? Openshift was a weird case where the enterprise version is out there, but the upstream wasn't! At least not useable

Is Openshift an extremely wellfunded solution seeking a problem?

It's a well-funded solution to a well-funded problem.

Producing platforms for enterprise customers is truly, genuinely difficult. There is enormous variation and complexity between and within customers, which cannot be dismissed easily.

Disclosure: I work for VMware, a direct competitor in this space.

Is Vmware going to support an operator store like red hat?

If yes, is there a way to certify an operator on Vmware 7?

I'm not sure, to be honest. Can you email me? I'll try to figure out who I can connect you to for an answer when I'm back on Monday.

Sure. will do. Thank you for your reply.

Im not knowledgable enough in this area, but I don't understand the value in using Openshift's custom setup over established cloud providers setups like AWS or GCP or Azure or even VMWare(who has been in the vm biz wayyy longer than all of these players.)

The value prop depends a lot on who you are and what you have. The massive selling point to many enterprises that own their own hardware is that they can run OpenShift on their metal, and augment with public clouds (AWS/GCP/Azure). If you use any of the vendor-specific augmentations (like ALB integration) you can't leave AWS and move to another cloud or your own hardware.

OpenShift also adds a lot of rich functionality above the standards K8s setup. It's essentially a bunch of operators that work really well together and add PaaS functionality onto K8s.

Disclaimer: I work for Red Hat Consulting where my day job is 100% OpenShift.

The "custom" parts of OpenShift are things you're going to want anyways. They're also optional (to a point) but obviously Supportability will change depending on customer customization. A Container Registry, something to manage your Ingress (we have HAProxy and Ingress Controller), Metrics & Monitoring of containers, pods, and nodes using Prometheus, Grafana, and AlertManager, a logging stack that sucks in your logs from stdout built on Elasticsearch, Fluentd, and Kibana, supported Middleware, Apache Camel, AMQ, Kafk), Java, OpenJDK, JBoss, Tomcat, Spring Boot, node.js, Quarkus, Python, Ruby, PHP stacks, built-in tooling for CI/CD with Jenkins, Tekton. OpenShift can be run almost anywhere that RHEL8 can. We've started down the path of multi-arch supported Kubernetes too, first with IBM Z and others to come. We run OpenShift on Public Clouds, Private Clouds, VMs and Baremetal.

You forgot to mention Erlang, MongoDB, Rebol, zsh, PostgreSQL, Haskell, Microsoft .NET Compact Framework 3.9, DB2, Ansible, NetBSD and an elastic scalable automated deployment and analysis stack based on virtualized Visual Basic 6.

Any company needs that, and more! I'm glad Red Hat consultants are here to help us make sense of all those technologies.

Everything you named is common to every cloud provider.....container registry, load balancers, log monitoring, etc

It's actually also doable with K8's and Helm.

I only have a birds eye view but I can tell so far, it seems like yall are providing the much-needed synergy, organic innovation and turnkey platform insights to those vertically and horizontally aligned paradigm holistically reimagined out of the box future forward dynamic enterprises to both meet market demand and to transform industry mindshare with world class artisinal I.P.

I.P.A if you will.

Every technology V.P. will get a visible hard-on when they hear about the Open shift product.

Disclosure: I work for Red Hat, working with the Red Hat Developer Group.

For those without a convenient OpenShift cluster, there are at least a few free options.

- https://learn.openshift.com/ has 'playgrounds' to allow temporary access

- CodeReady Containers is a virtualized desktop OpenShift cluster you can run on a laptop

For learners-- OpenShift is Kubernetes. Great stuff!

> Completely client based. No server is required within the OpenShift cluster for deployment.

So I do need a OpenShift cluster then? Confusing.

I think it means that any existing OpenShift cluster is equipped with the necessary infrastructure and APIs exposed so that there is no Odo-specific server component required.

I agree the wording is unfortunate. Kinda like "serverless".

Yeah, OpenShift cluster is the server for this tool - saying it is fully client based because it doesn't need additional server is - I don't know what :) (Besides the tool it is replacing - oc - doesn't need another server either.)

`oc` does need a server for a lot of things, unfortunately. Just do a `oc [...] --loglevel=9` to see what it's doing.

And what server would that be - the OpenShift master/API server right? That's the one. But it's the same with odo. None need an additional server is what I was saying.

What is the difference between this tool (odo) and something like Bosh ?

Reply on news.ycombinator.com