ITSB are a proud Red Hat Advanced Business Partner. The following article is reposted from Redhat.com full credit goes to the Red Hat team. 

We are pleased to announce the release of Red Hat CodeReady Workspaces 2.0. Based on Eclipse Che, its upstream project CodeReady Workspaces is a Red Hat OpenShift-native developer environment enabling cloud-native development for developer teams.

CodeReady Workspaces 2.0 is available now on OpenShift 3.11 and OpenShift 4.x.

This new version introduces:

• Kubernetes-native developer sandboxes on OpenShift: Bring your Kubernetes application into your development environment, allowing you to code, build, test, and run as in production.
• Integrated OpenShift experience: OpenShift plugin and integration into the OpenShift 4 Developer Console.
• New editor and Visual Studio (VS) Code extensions compatibility: New browser-based editor, providing a fast desktop-like experience and compatibility with Visual Studio Code extensions.
• Devfile, developer environment as code: Developer environments are codified with a devfile making them consistent, repeatable, and reproducible.
• Centrally hosted on OpenShift with AirGap: Deploy on your OpenShift cluster, behind your firewall. AirGap capabilities. Easier to monitor and administer.

Kubernetes-native developer sandboxes on OpenShift

CodeReady Workspaces 2.0 provides developer environments that are Kubernetes pods running on OpenShift. In those sandboxes are the components and tools needed to code on a project: a browser-based editor, the plugins, the tools, and the different runtimes required for your project. Everything is running in containers, providing highly consistent, repeatable, and reproducible developer environments—zero config needed, zero pain.

In this new version, everything you need in your developer environment is fully containerised, even the editor and its plugins. CodeReady Workspaces isolates the tools from your application runtime, allowing you to bring your Kubernetes application into your developer sandbox, code on your application, and run it as in production. The tools are running in sidecar containers and packaged with their own dependencies, making the configuration of your developer environment smooth and keeping your application runtimes untainted from the tools you are using.

With CodeReady Workspaces, you can code directly on OpenShift, bring your Kubernetes application into your developer sandbox, and code and run your code as close as possible to how it will run on production.

Integrated OpenShift experience

CodeReady Workspaces 2.0 enables developers to create applications running on OpenShift easily. Developers benefit from an integrated experience, providing a fast turnaround in the inner-loop development process.

An OpenShift plugin is available to speed up OpenShift development. Developers can connect to any OpenShift cluster and create, debug, and deploy directly from CodeReady Workspaces.

This plugin leverages OpenShift Do (odo) to simplify inner-loop development and OpenShift CLI (oc) to help you interact with the OpenShift instance and enriching the inner-loop experience. It is compatible with OpenShift instances (3.11 or 4.x) and supporting public cloud instances, such as Red Hat OpenShift on Azure and AWS.

New editor and VS Code extension compatibility

CodeReady Workspaces 2.0 provides a new default editor based on Eclipse Theia. Developers can enjoy a responsive, desktop-like experience that feels familiar.

This new default editor also brings compatibility with VS Code extensions. The plugin registry provided with CodeReady Workspaces already package tools for the most popular languages: JavaScript, Java, Python, .NET, Go, PHP, XML, and Yaml. You’ll also find tools for OpenShift. Bringing an existing plugin from VS Code is simple; the main difference is in the way the plugins are packaged. On CodeReady Workspaces, plugins are delivered with their dependencies in their own container and running as a sidecar in the workspace pod.

With the new version of CodeReady Workspaces, developers benefit from a richer editing experience with:

• Command palette: Full keyboard navigation.
• Rich editor: Find/Replace instances, peek definition, outline view.
• Debugger: Integrated debugging experience.
• Git: Native Git experience, visual indicators for changes in project explorer and editor.
• Layout customization: Configure the layout with drag & drop.
• Theming: White or black themes are available out of the box.
• Security: Secured communication between the editor, the end user, and the workspace.
• Extended tasks: Handles the CodeReady Workspaces commands and provides the ability to start those into a specific container of the workspace.
• Extended terminal: Allows providing a terminal for any of the containers of the workspace pod.
• Workspace plugin: Provides a view that shows all the containers that are running in the workspace and allows interacting with them.
• Ports plugin: Allows detecting when services are running inside of the workspace and automatically expose them.

Air-gapped capabilities

CodeReady Workspaces supports installation in a restricted environment. This includes your own private cloud, disconnected from the public internet.

CodeReady Workspaces can be configured to rely on your private image registry. The different components needed for CodeReady Workspaces will be installed and configured so that they use only your internal resources.

The workspaces pod, with the tools and the different plugins, also can be configured to:

• Leverage your private Git repositories.
• Leverage your runtime containers from your own container registries.
• Rely on your own maven, npm, or any dependency repository you have.

For installation, follow the documentation instructions for OpenShift Container Platform 3.11 and OpenShift Container Platform 4.x.

Devfile, developer environment as code

The devfile provides easy to configure, reproducible definitions of portable developer environments.

The devfile is a declarative abstraction of a developer workspaces, which includes the runtime environments of the application, the source code of the projects mapped to repositories and the tools, plugins, and commands needed to code, build, test, run, and debug an application. This makes the developer workspace replicable. You can use your OpenShift application definition with your devfile; just “dev-mode” it by supercharging the tools you need to code on it.

Once you have a devfile configured for your project, you can host it on your source code repository.

With the devfile definition and CodeReady Workspaces, developer environments are becoming fully codified, and easily can be modified, shared, forked, and extended. You don’t need to mess with hard-to-maintain and hard-to-manage documentation, VMs, and dockerfiles, which provide only a partial solution on setting up a developer environment.

Try CodeReady Workspaces 2.0 now

CodeReady Workspaces 2.0 is available now on OpenShift 3.11 and OpenShift 4.x:

• See the OpenShift 3.11 installation instructions.
• On OpenShift 4.x, you can install directly from Operator Hub and follow the documentation.
• Download the Red Hat CodeReady Workspaces CLI.
• Visit the Red Hat CodeReady Workspaces product page.

ITSB are a proud Red Hat Advanced Business Partner. The following article is reposted from Redhat.com full credit goes to the Red Hat team. 

Last week we celebrated the 25th anniversary of Red Hat’s inaugural Halloween release. This week? We’ve got Red Hat Enterprise Linux 8.1 hitting the streets on schedule and ready to take on your toughest workloads. In RHEL 8.1 we have some new tools, live kernel patching, a new system role, and more. Here’s a quick preview of the highlights in RHEL 8.1.

Live Patching updates for 8.1 and 7.7

RHEL 8.1 marks the first release of RHEL 8 that will receive live kernel patches for critical and selected important CVEs, and no premium subscription is required. They will be delivered via the regular content stream and can be consumed via Yum updates. (Previously, these were on request for premium subscription customers and “hand delivered.”) The goal of the program is to minimize the need to reboot systems in order to get the latest critical security updates.

The live patches will be issued for releases with a current or planned EUS stream, and for kernels that are up to one year old. As of this writing, that’s going to be 7.6, 7.7, 8.1, and are planned to include 8.2 when released. Live patches will remain available during the EUS and E4S extended support periods, as long as the kernels are less than a year old.

Note that this is kernel patching only at this time. We are looking at userspace patching for glibc and OpenSSL libraries, but that isn’t currently available.

Security

When we ask customers about their priorities, security floats towards the top of the list with great regularity. It’s a fundamental consideration that seems obvious, but we can’t take it for granted–and we continue to think about ways that we can help you make your systems more secure. 

Whether that’s through new features to harden systems, more aggressive security policies, or tools to help you avoid security pitfalls, we take an aggressive approach to improving security in RHEL.

Application whitelisting

One way to boost security is to limit the applications a system can run. With RHEL 8.1 we’re introducing application whitelisting so that admins can add specific applications to be allowed to run, and deny anything else. 

Whitelisting in RHEL 8.1 uses the RPM database and an administrator-supplied list of approved applications. 

Updated CVE Policy

Technically this change isn’t specific to RHEL 8.1, but in case you missed it when we announced it earlier it’s worth calling out. On October 2nd we announced that we have expanded the scope of coverage for CVEs to help reduce the risk profile of customers and help maintain greater stability of their deployments. For more, check out Mark Thacker’s coverage of this on the Red Hat Blog.

SELinux for Containers

If you’ve been watching the blog for RHEL news, you probably caught Lukas Vrabec’s post in September on generating SELinux policies for containers using Udica. For situations when the default container SELinux policy for containers is too strict or otherwise needs modification we’re providing Udica to help generate a custom policy for the containers.

Udica detects which Linux capabilities are required by the container and works to create a SELinux rule allowing all these capabilities. It supports generating policies for containers using Podman and Docker, and support for CRI-O is expected in the near future. Be sure to read Lukas’ post for the full picture on Udica and how you can make use of it in RHEL 8.1.

Containers

In addition to Udica, with RHEL 8.1 we have several other updates related to containers to call your attention to. First up, we have new tools for container management in the web console as part of our ongoing efforts to simplify RHEL management.

Another feature that we’re very excited about in 8.1 is full support of rootless containers. We’ve been talking about this for a while, but with 8.1 it’s going to be much easier for users to get their hands on. Why do you want rootless containers? The short version is that it’s better to run containers with fewer privileges, just as you would any other process. See Scott McCarty’s post on rootless containers for more on how to use them and why you’d want to.

Ideally you only install the tools and applications you need on a system when it’s put into production. But sometimes you need to troubleshoot a system, and need additional tools that weren’t rolled out with the system. That’s why we are adding Toolbox to RHEL 8.1. We’ve added a toolbox container for one-off troubleshooting that you can zip onto a system when you need to fix it without altering the overall state of the system.

And we’ve made that easy to do by using `yum install toolbox` as a method to add this container to your system with the necessary tools to run it. Look for a blog in the next few weeks that will walk through running toolbox in greater detail.

Upgrades

One of the improvements in RHEL 8.1 is expanded options for in-place upgrades from RHEL 7 to RHEL 8. With the GA of 8.1 we now support in-place upgrades for 64-bit ARM, pseries, and zseries architectures, along with x86_64 systems.

Predictable cadence

One of the major features in the 8.1 release isn’t a what, it’s a when. As in “when is the next RHEL release coming?” In about six months. When’s the next one? About six months after that. And so on.

Why does this matter? Because our users, customers, partners, and others need to make plans around RHEL releases. They need to have a good picture of when releases are coming, how long they have to wait for new features, our vendor friends want to know when they can expect hardware support to land in RHEL for their customers, and so forth.

We also know that the time-based model works well for development. Features that aren’t going to make the cut get held back for the next release. And the next release is only six months out, so it’s okay to hold off when needed.

At Red Hat Summit this year we talked about our plans to deliver RHEL on a six-month cycle, and to have a predictable and simpler cadence with RHEL releases. And here we are, six months later with RHEL 8.1. In addition, RHEL 8.1 will be the first RHEL 8 minor release to offer Extended Update Support (24 months from the minor release general availability).  In addition to RHEL 8.1, EUS will be available on even numbered RHEL minor releases through the 5 year Full Support Phase. (Please see the Red Hat Enterprise Linux Life Cycle Overview page for all the details on the RHEL LIfe Cycle and EUS policy) We should add that in keeping with this, RHEL 7.8 Beta is also now available for download in the customer portal.

If you fancied discussing any of the points in this article further then please email us on hello@itsb.co.uk or give us a call on 03333 44 22 04