The Evolution of a Linux Container

(Probably, a more accurate title would be “The Evolution of a Linux Container Developer”)

Since .NET now runs on Linux (as well as Windows and macOS), the whole world of Linux containers and microservices has opened up to .NET developers. With a large pool of developers, a long track record of success, and performance numbers that are impressive, .NET offers a great opportunity to expand the world of Linux containers to formerly Windows-centric developers.

While it’s tempting to rush in — and I am the first to say, “go for it” — there are some nuances which should not be missed when running .NET code inside a Linux container. It’s far too easy to push some code into an image and be done. After all, everything happens so quickly, surely all is well. Right?

Continue reading “The Evolution of a Linux Container”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.

Creating your first ASP.NET MVC web site on RHEL

Follow this blog post, and within minutes you will have an ASP.NET MVC website running on Red Hat Enterprise Linux (RHEL). Yes, I’m talking to you, Windows .NET developer; you’re about to double your OS skillset. Let’s do this.

Continue reading “Creating your first ASP.NET MVC web site on RHEL”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.

End To End Encryption With OpenShift Part 1: Two-Way SSL

This is the first part of a 2 part article, part 2 (End To End Encryption With OpenShift Part 2: Re-encryption) will be authored by Matyas Danter, Sr Consultant with Red Hat, it will be published soon.

This article aims to demonstrate use cases for Openshift routes to achieve end-to-end encryption. This is a desirable and sometimes mandated configuration for many verticals, which deal with strict regulations.

Continue reading “End To End Encryption With OpenShift Part 1: Two-Way SSL”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.


For more information about Red Hat OpenShift and other related topics, visit: OpenShift, OpenShift Online.

Using Pipelines in OpenShift 3.3+ for CI/CD

It’s been a while since Red Hat released version 3.3 of OpenShift Container Platform, this version is full of features.

One of my favorites is the support for Pipelines (Tech Preview for now) that lets you easily integrate Jenkins builds on your OpenShift (Origin) Platform.

OpenShift Pipelines

OpenShift Pipelines are based on the Jenkins Pipeline plugin. (https://jenkins.io/solutions/pipeline/)

Integrating Jenkins Pipelines into OpenShift unlocks all the features for the CI/CD world enabling its users to easily manage repeatable tasks in the easiest way.

As you can imagine OpenShift lets you run a containerized version of the Jenkins container in one of your projects and then, after setting the right permission for the Jenkins’ ServiceAccount, it’ll do the job for you.

Pipelines are nothing more than a BuildConfig with type ‘JenkinsPipeline’.

But let’s take a more in-depth look using this simple scenario below:

  1. Jenkins OpenShift project: The base project, handling the Jenkins container and all the pipelines.
  2. Development OpenShift project: The project used for the development environment, it will handle the BuildConfig for building the app from source.
  3. Testing OpenShift project: The project used for the testing environment, it will not use any BuildConfig and it’ll expect ImageStream to be the only source for new deployments.

We’ll create two Pipelines that will simulate a Continuous Integration scenario:

  • Development Pipeline: It will trigger the BuildConfig for the development project and handle its deployment.
  • Testing Pipeline: It will handle the tagging/pulling/pushing operations to let the image flow from development project to testing project and then it will schedule a new deployment.

OpenShift start

First of all, I’ll start my OpenShift cluster, you can skip to the next section in case you’re already up & running.

For running OpenShift on my laptop, the easiest and fastest method I found is “oc cluster up”. All you need to do is to have a working Linux container daemon and an updated origin-clients package. On Fedora 25 I’ve successfully installed “origin-clients-1.3.1” from the default repos.

So that’s all, let’s “oc cluster up” my OpenShift platform:

[alex@freddy ~]$ oc cluster up --host-data-dir=/var/lib/origin/openshift.local.data --use-existing-config --version=v1.3.1 --public-hostname=192.168.123.1
-- Checking OpenShift client ... OK
-- Checking Docker client ... OK
-- Checking Docker version ... OK
-- Checking for existing OpenShift container ... Deleted existing OpenShift container
-- Checking for openshift/origin:v1.3.1 image ... OK
-- Checking Docker daemon configuration ... OK
-- Checking for available ports ...
-- Checking type of volume mount ... Using nsenter mounter for OpenShift volumes
-- Creating host directories ... OK
-- Finding server IP ... Using public hostname IP 192.168.123.1 as the host IP Using 192.168.123.1 as the server IP
-- Starting OpenShift container ...
Starting OpenShift using container 'origin'
Waiting for API server to start listening
OpenShift server started
-- Installing registry ... OK
-- Installing router ... OK
-- Importing image streams ... OK
-- Importing templates ... OK
-- Login to server ... OK
-- Creating initial project "myproject" ...
Now using project "myproject" on server "https://192.168.123.1:8443".
-- Server Information ...
OpenShift server started.
The server is accessible via web console at:
https://192.168.123.1:8443
You are logged in as:
User: developer
Password: developer
To login as administrator:
oc login -u system:admin

Please note: I’ve manually created the “host-data” folder, the other options used are self-explanatory.

The Jenkins project

We should now be ready to sign into our OpenShift platform. openshift-first-login

Now, let’s create our first project, the Jenkins project: fireshot-capture-35-openshift-web-console-https___192-168-123-1_8443_console_create-project

Select the “Jenkins ephemeral” template. fireshot-capture-36-openshift-web-console_-https___192-168-123-1_8443_console

Leave all the parameters set to default and press create. At the end, you should see a notice like the following: Make a note of the generated password. You may need this in the future. (Anyway you can easily recover it should you need it).

fireshot-capture-37-openshift-web-console_-https___192-168-123-1_8443_console

Enabling Pipelines feature (currently in Tech Preview)

As you can see by clicking on the Builds tab menu, there is no trace of the Pipelines support. As specified in the title this feature is a tech preview, so we need to activate it. fireshot-capture-40-openshift-web-conso_-https___127-0-0-1_8443_console_project_jenkins_overview

For activating the Pipelines feature we need to create a JS config file, for enabling it:

# echo "window.OPENSHIFT_CONSTANTS.ENABLE_TECH_PREVIEW_FEATURE.pipelines = true;" >> /var/lib/origin/openshift.local.config/master/tech-preview.js

Please note: You can create the file in a location you prefer. Then we need to inject the file through the master-config.yaml file, in my case, using “oc cluster up”, it’s located in “/var/lib/origin/openshift.local.config/master/”. Place the following lines in your config file:

assetConfig: ... extensionScripts: - /var/lib/origin/openshift.local.config/master/tech-preview.js

Then restart your OpenShift master. You should then be able to find the Pipelines section under the Builds tab: fireshot-capture-41-openshift-web-conso_-https___127-0-0-1_8443_console_project_jenkins_overview

We’re almost ready to start working on our pipelines.

The development project

We can now create the development project, which we’ll use as a root for source building:

$ oc new-project development --display-name="Development" --description="Development project"
Now using project "development" on server "https://192.168.123.1:8443".

We can now use the template I just prepared for our development environment. In this demo, we’ll use the nodejs-example application available in the standard set of the OpenShift templates. Let’s populate the just created development project:

$ oc new-app https://raw.githubusercontent.com/alezzandro/nodejs-ex/master/openshift/templates/nodejs-dev.json
--> Deploying template nodejs-example for "https://raw.githubusercontent.com/alezzandro/nodejs-ex/master/openshift/templates/nodejs-dev.json"

Node.js
———
This is an example of a Node.js application with no database. For more information about using this template, including OpenShift considerations, see https://github.com/openshift/nodejs-ex/blob/master/README.md.

The following service(s) have been created in your project: nodejs-example.

For more information about using this template, including OpenShift considerations, see https://github.com/openshift/nodejs-ex/blob/master/README.md.

* With parameters:
* Name=nodejs-example
* Namespace=openshift
* Memory Limit=512Mi
* Git Repository URL=https://github.com/alezzandro/nodejs-ex.git
* Git Reference=
* Context Directory=
* Application Hostname=
* GitHub Webhook Secret=cR48n2GX67ADfxwi63uGomiXjxgMUCEykekbNR0G # generated
* Generic Webhook Secret=Hvx3stEhQuAmKPnjaujQHvYFV1cl1cvmh4IjXnri # generated
* Database Service Name=
* MongoDB Username=
* MongoDB Password=
* Database Name=
* Database Administrator Password=
* Custom NPM Mirror URL=

–> Creating resources with label app=nodejs-example …
service “nodejs-example” created
route “nodejs-example” created
imagestream “nodejs-example” created
buildconfig “nodejs-example” created
deploymentconfig “nodejs-example” created
–> Success
Use ‘oc start-build nodejs-example’ to start a build.
Run ‘oc status’ to view your app.

As you can see by running “oc get pods”, no deployment has started so no pods will be seen. This is a wanted behavior because we want to manage the build process and the deployment through a Jenkins’ Pipeline. For achieving this, I’ve just edited the original nodejs-ex template and removed all the triggers from the DeploymentConfig. Looking at our development project we’ll have created the following elements at the end: A BuildConfig, an ImageStream, a DeploymentConfig, a Route and a Service.

$ oc get all
NAME
bc/nodejs-example
NAME
is/nodejs-example
NAME
dc/nodejs-example
NAME
routes/nodejs-example
NAME
svc/nodejs-example

The testing project

We can now setup the testing project, like the development project I’ve already set up a template, removing the BuildConfig section. We’ll promote the container built in the development project to testing, using Jenkins Pipeline. Let’s create and populate the environment:

$ oc new-project testing --display-name="Testing" --description="Testing project"
Now using project "testing" on server "https://192.168.123.1:8443".

You can add applications to this project with the ‘new-app’ command. For example, try:

oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-ex.git

to build a new example application in Ruby.

$ oc new-app https://raw.githubusercontent.com/alezzandro/nodejs-ex/master/openshift/templates/nodejs-test.json
–> Deploying template nodejs-example for “https://raw.githubusercontent.com/alezzandro/nodejs-ex/master/openshift/templates/nodejs-test.json”

Node.js
———
This is an example of a Node.js application with no database. For more information about using this template, including OpenShift considerations, see https://github.com/openshift/nodejs-ex/blob/master/README.md.

The following service(s) have been created in your project: nodejs-example.

For more information about using this template, including OpenShift considerations, see https://github.com/openshift/nodejs-ex/blob/master/README.md.

* With parameters:
* Name=nodejs-example
* Namespace=openshift
* Memory Limit=512Mi
* Git Repository URL=https://github.com/alezzandro/nodejs-ex.git
* Git Reference=
* Context Directory=
* Application Hostname=
* GitHub Webhook Secret=XFlNUpDsLBotlrcyAnRQdLkKyq65iKE6xOMxqQr5 # generated
* Generic Webhook Secret=LX3PdBcU4dTKPyvTi8aw02VeXBjCxuJpyA7kgV8c # generated
* Database Service Name=
* MongoDB Username=
* MongoDB Password=
* Database Name=
* Database Administrator Password=
* Custom NPM Mirror URL=

–> Creating resources with label app=nodejs-example …
service “nodejs-example” created
route “nodejs-example” created
imagestream “nodejs-example” created
deploymentconfig “nodejs-example” created
–> Success
Run ‘oc status’ to view your app.

As you can see by running “oc get pods”, no deployment has started so no pods will be seen. This is a wanted behavior because we want to manage the deployment through a Jenkins’ Pipeline. For achieving this, I’ve just edited the original nodejs-ex template and removed all the triggers from the DeploymentConfig. Looking at our testing project we’ll have at the end the following elements created:

$ oc get all
NAME
is/nodejs-example
NAME
dc/nodejs-example
NAME
routes/nodejs-example
NAME
svc/nodejs-example

Please note: As I said before, there is no BuildConfig, we’ll promote the container built in the development project to testing, using Jenkins Pipeline.

Pipelines definition and import

Ok, we’re now ready to define our Pipelines. I’ve prepared two Jenkins’ pipelines, one for the development project and one for the testing project. Return back to the Jenkins project and import the two BuildConfigs containing the pre-configured pipelines:

$ oc project jenkins
Now using project "jenkins" on server "https://192.168.123.1:8443".

$ oc create -f https://raw.githubusercontent.com/alezzandro/nodejs-ex/master/openshift/pipeline/development-pipeline.yaml
buildconfig “development-pipeline” created

$ oc create -f https://raw.githubusercontent.com/alezzandro/nodejs-ex/master/openshift/pipeline/promote2testing-pipeline.yaml
buildconfig “testing-pipeline” created

$ oc get bc
NAME TYPE FROM LATEST
development-pipeline JenkinsPipeline 0
testing-pipeline JenkinsPipeline 0

We can now take a look a what the two pipelines will be able to do.

Jenkins development pipeline

apiVersion: v1
kind: BuildConfig
metadata:
annotations:
pipeline.alpha.openshift.io/uses: '[{"name": "nodejs-example", "namespace": "development",
"kind": "DeploymentConfig"}]'
creationTimestamp: 2016-12-22T13:54:23Z
labels:
app: jenkins-pipeline-development
name: development-pipeline
template: application-template-development-pipeline
name: development-pipeline
namespace: jenkins
resourceVersion: "5781"
selfLink: /oapi/v1/namespaces/jenkins/buildconfigs/development-pipeline
uid: 24c166c2-c84e-11e6-b4f7-68f7286606f4
spec:
output: {}
postCommit: {}
resources: {}
runPolicy: Serial
source:
type: None
strategy:
jenkinsPipelineStrategy:
jenkinsfile: |-
node('maven') {
stage 'build'
openshiftBuild(buildConfig: 'nodejs-example', showBuildLogs: 'true', namespace: 'development')
stage 'deploy'
openshiftDeploy(deploymentConfig: 'nodejs-example', namespace: 'development')
}
type: JenkinsPipeline
...

As you can see this BuildConfig’s type is: “JenkinsPipeline” with a well-defined “JenkinsPipelineStrategy” defined through a “JenkinsFile”. The pipeline itself is composed of two stages:

  1. Build: we start the build process in the project/namespace “development” through the “BuildConfig” named: “nodejs-example”.
  2. Deploy: after the build, we can then start a new deployment in the project/namespace “development” through the “DeploymentConfig” named: “nodejs-example”.

 

Jenkins testing pipeline

$ oc get bc/testing-pipeline -o yaml
apiVersion: v1
kind: BuildConfig
metadata:
annotations:
pipeline.alpha.openshift.io/uses: '[{"name": "nodejs-example", "namespace": "testing",
"kind": "DeploymentConfig"}]'
creationTimestamp: 2016-12-22T13:54:30Z
labels:
app: jenkins-pipeline-testing
name: testing-pipeline
template: application-template-testing-pipeline
name: testing-pipeline
namespace: jenkins
resourceVersion: "5994"
selfLink: /oapi/v1/namespaces/jenkins/buildconfigs/testing-pipeline
uid: 292fa5e5-c84e-11e6-b4f7-68f7286606f4
spec:
output: {}
postCommit: {}
resources: {}
runPolicy: Serial
source:
type: None
strategy:
jenkinsPipelineStrategy:
jenkinsfile: |-
node('maven') {
stage 'tag'
openshiftTag(namespace: 'development', sourceStream: 'nodejs-example', sourceTag: 'latest', destinationNamespace: 'testing', destinationStream: 'nodejs-example', destinationTag: 'latest')
stage 'deploy'
openshiftDeploy(deploymentConfig: 'nodejs-example', namespace: 'testing')
}
type: JenkinsPipeline
...

As in the previous BuildConfig, you can see this BuildConfig’s type is: “JenkinsPipeline” with a well-defined “JenkinsPipelineStrategy” defined through a “JenkinsFile”. The pipeline itself is composed of two stages:

  1. Tag: we tag the latest ImageStream built on “development” project, setting the destination to “testing” project. Through this action, we’re promoting the image from dev to test environment.
  2. Deploy: after the image promotion, we can then deploy the new image in the “testing” project through the “DeploymentConfig” named: “testing”.

 

Jenkins Service Account

Now, we need to enable Jenkins service account (sa) to access and edit resources on “development” and “testing” project:

$ oc policy add-role-to-user edit system:serviceaccount:jenkins:jenkins -n testing
$ oc policy add-role-to-user edit system:serviceaccount:jenkins:jenkins -n development

Run the pipelines!

We’re now ready to see the pipelines in action! You can access the Pipelines page through Builds->Pipelines. 

We’re almost ready, just click on the “Start Pipeline” button for the “development-pipeline”. You’ll see the Build starting and moving forward:

Clicking on the “View Log” link will redirect you to the Jenkins login page. You can gain access through user “admin” and the generated password. The password is in the environment variables for the Jenkins pod.

At end of the process, you’ll see all the steps completed and marked in green:

We now have at least one image ready for the promotion process. We can start the testing-pipeline:

Finally, we can check the result by querying OpenShift using the web interface: Development project:

Testing project:

Or by console:

$ oc project development
Now using project "development" on server "https://192.168.123.1:8443".

$ oc get pods
NAME READY STATUS RESTARTS AGE
nodejs-example-1-build 0/1 Completed 0 23m
nodejs-example-1-trurc 1/1 Running 0 22m

$ oc project testing
Now using project “testing” on server “https://192.168.123.1:8443”.

$ oc get pods
NAME READY STATUS RESTARTS AGE
nodejs-example-1-b1kcf 1/1 Running 0 19m

That’s all! Should you have any doubts, please comment!

About Alessandro

Alessandro Arrichiello is a Platform Consultant for Red Hat Inc. He has a passion for GNU/Linux systems, that began at age 14 and continues today. He worked with tools for automating Enterprise IT: configuration management and continuous integration through virtual platforms. He’s now working on distributed cloud environment involving PaaS (OpenShift), IaaS (OpenStack) and Processes Management (CloudForms), Containers building, instances creation, HA services management, workflows build.


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 


For more information about Red Hat OpenShift and other related topics, visit: OpenShift, OpenShift Online.

Welcome to Red Hat Enterprise Linux, MSBuild, a build tool for .NET Core CLI!

Microsoft announced the first “alpha” release of the new MSBuild-based .NET Core tools. .NET Core SDK which can be downloaded from the Red Hat Developer Program site consists of .NET Core Runtime and .NET Core command line tools (.NET Core CLI). (Reminder – you must have a Red Hat Enterprise Linux subscription first.  If you don’t, you can go here for a no-cost subscription.) The MSBuild tool is included in .NET Core 1.0 preview 3 (not in the latest release .NET Core 1.1). The version number is something complicated because .NET CLI is not GA but still under preview. The MSBuild tool can be used with both .NET Core 1.0 and .NET Core 1.1 runtimes. RHEL is not listed in the .NET Core SDK 1.0 Preview 3 download list. But you can try MSBuild with the .NET Core CLI daily build.

NOTE: Red Hat has just released .NET Core 1.1. However, .NET Core 1.1 doesn’t include the MSBuild tool, you can try MSBuild following this blog.

Continue reading “Welcome to Red Hat Enterprise Linux, MSBuild, a build tool for .NET Core CLI!”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.

Installing Red Hat Developer Studio 10.2.0.GA through RPM

With the release of Red Hat JBoss Developer Studio 10.2, it is now possible to install Red Hat JBoss Developer Studio as an RPM. It is available as a tech preview. The purpose of this article is to describe the steps you should follow in order to install Red Hat JBoss Developer Studio.

Red Hat Software Collections

JBoss Developer Studio RPM relies on Red Hat Software Collections. You don’t need to install Red Hat Software Collections but you need to enable the Red Hat Software Collections repositories before you start the installation of the Red Hat JBoss Developer Studio.

Enabling the Red Hat Software Collections base repository

The identifier for the repository is rhel-server-rhscl-7-rpms on Red Hat Enterprise Linux Server and rhel-workstation-rhscl-7-rpms on Red Hat Enterprise Linux Workstation.

The command to enable the repository on Red Hat Enterprise Linux Server is:

sudo subscription-manager repos --enable rhel-server-rhscl-7-rpms

The command to enable the repository on Red Hat Enterprise Linux Workstation is:

sudo subscription-manager repos --enable rhel-workstation-rhscl-7-rpms

For more information, please refer to the Red Hat Software Collections documentation.

JBoss Developer Studio repository

As this is a tech preview, you need to manually configure the JBoss Developer Studio repository.

Create a file /etc/yum.repos.d/rh-eclipse46-devstudio.repo with the following content:

[rh-eclipse46-devstudio-stable-10.x]
name=rh-eclipse46-devstudio-stable-10.x
baseurl=https://devstudio.redhat.com/static/10.0/stable/rpms/x86_64/
enabled=1
gpgcheck=1
upgrade_requirements_on_install=1
metadata_expire=24h

Red Hat developer signing key

As this is a tech preview, you need to accept the Red Hat developer signing key that has been used for producing the JBoss Developer Studio RPM.

Execute the following command:

sudo rpm --import "https://www.redhat.com/security/a5787476.txt"

Install Red Hat JBoss Developer Studio

You’re now ready to install Red Hat JBoss Developer Studio through RPM.

Enter the following command:

sudo yum install rh-eclipse46-devstudio

Answer ‘y’ when asked and after all required dependencies have been downloaded and installed, Red Hat JBoss Developer Studio is available on your system through the standard update channel !!!

You should see messages like the following:

rh eclipse46 devstudio.log

Launch Red Hat JBoss Developer Studio

From the system menu, mouse over the Programming menu, and the Red Hat Eclipse menu item will appear.

programming menu

Select this menu item and Red Hat JBoss Developer Studio user interface will appear then:

devstudio

Enjoy!

Jeff Maury 


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.

Getting Started with Microsoft SQL Server on Red Hat Enterprise Linux

Microsoft announced SQL Server on Linux public preview, so now you can try SQL Server on your Red Hat Enterprise Linux server. I’ll describe how to start SQL Server on RHEL.

Install and connect with CLI on RHEL

Microsoft publishes a step-by-step document how to Install SQL Server on Red Hat Enterprise Linux. It’s only 7 steps to install and run.

# systemctl status mssql-server
● mssql-server.service - Microsoft(R) SQL Server(R) Database Engine
   Loaded: loaded (/usr/lib/systemd/system/mssql-server.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2016-11-16 20:59:33 EST; 1 weeks 1 days ago
 Main PID: 77982 (sqlservr)
   Memory: 753.6M
   CGroup: /system.slice/mssql-server.service
           ├─77982 /opt/mssql/bin/sqlservr
           └─77997 /opt/mssql/bin/sqlservr

Now you can connect to SQL Server on RHEL. At first, let’s connect with sqlcmd. You should have to install SQL Server tools even if you run sqlcmd on the same host as you installed mssql-server package with following the document. First connect to local SQL Server instance.

Continue reading “Getting Started with Microsoft SQL Server on Red Hat Enterprise Linux”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.

Cockpit: Your entrypoint to the Containers Management World

Containers are one of the top trend today. Starting working or playing with them could be really hard also if you’ve well understood the theory at their base.

With this article I’ll try to show you some useful tips and tricks to start into containers world, thanks also to the great web interface provided by the Cockpit project.

cockpit--capture-15-cockpit-project-http___cockpit-project-org_

Cockpit overview

Cockpit is an interactive server admin interface.  You’ll find below some a of its great features:

  • Cockpit comes “out of the box” ready for the admin to interact with the system immediately, without installing stuff, configuring access controls, making choices, etc.
  • Cockpit has (as near as makes no difference) zero memory and process footprint on the server when not in use. The job of a server is not to show a pretty UI to admins, but to serve stuff to others. Cockpit starts on demand via socket activation and exits when not in use.
  • Cockpit does not take over your server in such a way that you can then only perform further configuration in Cockpit.
  • Cockpit itself does not have a predefined template or state for the server that it then imposes on the server. It is imperative configuration rather than declarative configuration.
  • Cockpit dynamically updates itself to reflect the current state of the server, within a time frame of a few seconds.
  • Cockpit is firewall friendly: it opens one port for browser connections: by default that is 9090.
  • Cockpit can look different on different operating systems, because it’s the UI for the OS, and not a external tool.
  • Cockpit is pluggable: it allows others to add additional UI pieces.

Continue reading “Cockpit: Your entrypoint to the Containers Management World”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.

Docker project: Can you have overlay2 speed and density with devicemapper? Yep.

It’s been a while since our last deep-dive into the Docker project graph driver performance.  Over two years, in fact!  In that time, Red Hat engineers have made major strides in improving container storage:

All of that, in the name of providing enterprise-class stability, security and supportability to our valued customers.

As discussed in our previous blog, there are a particular set of behaviors and attributes to take into account when choosing a graph driver.  Included in those are page cache sharing, POSIX compliance and SELinux support.

Reviewing the technical differences between a union filesystem and devicemapper graph driver as it relates to performance, standards compliance and density, a union filesystem such as overlay2 is fast because

  • It traverses less kernel and devicemapper code on container creation (devicemapper-backed containers get a unique kernel device allocated at startup).
  • Containers sharing the same base image startup faster because of warm page cache
  • For speed/density benefits, you trade POSIX compliance and SELinux (well, not for long!)

There was no single graph driver that could give you all these attributes at the same time — until now.

How we can make devicemapper as fast as overlay2

With the industry move towards microservices, 12-factor guidelines and dense multi-tenant platforms, many folks both inside Red Hat as well as in the community have been discussing read-only containers.  In fact, there’s been a –read-only option to both the Docker project, and kubernetes for a long time.  What this does is create a mount point as usual for the container, but mount it read-only as opposed to read-write.  Read-only containers are an important security improvement as well as they reduce the container’s attack surface.  More details on this can be found in a blog post from Dan Walsh last year.

When a container is launched in this mode, it can no longer write to locations it may expect to (i.e. /var/log) and may throw errors because of this.  As discussed in the Processes section of 12factor.net, re-architected applications should store stateful information (such as logs or web assets) in a stateful backing service.  Attaching a persistent volume that is read-write fulfills this design aspect:  the container can be restarted anywhere in the cluster, and its persistent volume can follow it.

In other words, for applications that are not completely stateless an ideal deployment would be to couple read-only containers with read-write persistent volumes.  This gets us to a place in the container world that the HPC (high performance/scientific computing) world has been at for decades:  thousands of diskless, read-only NFS-root booted nodes that mount their necessary applications and storage over the network at boot time.  No matter if a node dies…boot another.  No matter if a container dies…start another.

Continue reading “Docker project: Can you have overlay2 speed and density with devicemapper? Yep.”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.


For more information about Red Hat OpenShift and other related topics, visit: OpenShift, OpenShift Online.

MACsec: a different solution to encrypt network traffic

MACsec is an IEEE standard for security in wired ethernet LANs. This blog , will give an overview of what MACsec is, how it differs from other security standards, and present some ideas about how it can be used.

  • MACsec is a Layer 2 protocol that relies on GCM-AES-128 to offer integrity and confidentiality, and operates over ethernet.
  • It can secure all traffic within a LAN, including DHCP and ARP, as well as traffic from higher layer protocols.
  • It is an  extension to 802.1X provides secure key exchange and mutual authentication for MACsec nodes.
  • IPsec (a Layer 3 security protocol) and TLS (a Layer 4 security protocol) offer different guarantees and can be a better fit, depending on the use case.

Continue reading “MACsec: a different solution to encrypt network traffic”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.