Alessandro Arrichiello

Solution Architect, Red Hat inc.

Alessandro Arrichiello

Alessandro Arrichiello is a Solution Architect for Red Hat Inc. He has a passion for GNU/Linux systems, which 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.

Areas of Expertise

RHEL, Containers, Cloud, Openstack, Openshift, ManageIQ, Storage

Recent Posts

Intro to Podman (Red Hat Enterprise Linux 7.6 Beta)

Intro to Podman (Red Hat Enterprise Linux 7.6 Beta)

aarrichi
By Alessandro Arrichiello

Red Hat Enterprise Linux (RHEL) 7.6 Beta was released a few days ago and one of the first new features I noticed is Podman. Podman complements Buildah and Skopeo by offering an experience similar to the Docker command line: allowing users to run standalone (non-orchestrated) containers. And Podman doesn’t require a daemon to run containers and pods, so we can easily say goodbye to big fat daemons.

Podman implements almost all the Docker CLI commands (apart from the ones related to Docker Swarm, of course). For container orchestration, I suggest you take a look at Kubernetes and Red Hat OpenShift.

Podman consists of just a single command to run on the command line. There are no daemons in the background doing stuff, and this means that Podman can be integrated into system services through systemd.

We’ll cover some real examples that show how easy it can be to transition from the Docker CLI to Podman.

Continue reading “Intro to Podman (Red Hat Enterprise Linux 7.6 Beta)”

Share
Customizing an OpenShift Ansible Playbook Bundle

Customizing an OpenShift Ansible Playbook Bundle

aarrichi
By Alessandro Arrichiello

Today I want to talk about Ansible Service Broker and Ansible Playbook Bundle. These components are relatively new in the Red Hat OpenShift ecosystem, but they are now fully supported features available in the Service Catalog component of OpenShift 3.9.

Before getting deep into the technology, I want to give you some basic information (quoted below from the product documentation) about all the components and their features:

  • Ansible Service Broker is an implementation of the Open Service Broker API that manages applications defined in Ansible Playbook Bundles.
  • Ansible Playbook Bundles (APB) are a method of defining applications via a collection of Ansible Playbooks built into a container with an Ansible runtime with the playbooks corresponding to a type of request specified in the Open Service Broker API specification.
  • Playbooks are Ansible’s configuration, deployment, and orchestration language. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process.

Continue reading “Customizing an OpenShift Ansible Playbook Bundle”

Share
Understanding Ansible Tower Isolated Nodes

Understanding Ansible Tower Isolated Nodes

aarrichi
By Alessandro Arrichiello

Today I want to talk of one of the great, brand new features that Ansible Tower introduced in version 3.2: Ansible Tower Isolated Nodes.

Thanks to this feature, you’ll be able to create an isolated (Ansible-Tower) node in a restricted network that will manage automation jobs for the main tower, reporting results!

To quote the release statement:

“A Tower Isolated Node is a headless Ansible Tower node that can be used for local execution capacity, either in a constrained networking environment such as a DMZ or VPC, or in a remote data center for local execution capacity. The only prerequisite is that there is SSH connectivity from the Tower Cluster to the Isolated Node. The Tower Cluster will send all jobs for the relevant inventory to the Isolated Node, run them there, and then pull the job details back into Ansible Tower for viewing and reporting.”

Continue reading “Understanding Ansible Tower Isolated Nodes”

Share
OpenShift 3.6 – Release Candidate (A Hands-On)

OpenShift 3.6 – Release Candidate (A Hands-On)

aarrichi
By Alessandro Arrichiello

Hi, Everybody!

Today I want to introduce you to some features of OpenShift 3.6 while giving you the chance to have a hands-on experience with the Release Candidate.

First of all:

  1. It’s a Release Candidate and the features I’ll show you are marked as Tech Preview, so use them for testing purpose ONLY!
  2. We cannot use Minishift just because there is no Minishift updated yet. Anyway, I’ll show how could use its base iso-image.
  3. I don’t want to use ‘oc cluster up’ in a virtual machine just because setting up a virtual machine, to run it, would be a waste of time.

Continue reading “OpenShift 3.6 – Release Candidate (A Hands-On)”

Share
The CoolStore Microservices Example: DevOps and OpenShift

The CoolStore Microservices Example: DevOps and OpenShift

aarrichi
By Alessandro Arrichiello

An introduction to microservices through a complete example

Today I want to talk about the demo we presented @ OpenShift Container Platform Roadshow in Milan & Rome last week.

The demo was based on JBoss team’s great work available on this repo:
https://github.com/jbossdemocentral/coolstore-microservice

Continue reading “The CoolStore Microservices Example: DevOps and OpenShift”

Share

Cockpit: Your entrypoint to the Containers Management World

aarrichi
By Alessandro Arrichiello

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”

Share
Understanding OpenShift Security Context Constraints

Understanding OpenShift Security Context Constraints

aarrichi
By Alessandro Arrichiello

OpenShift gives its administrators the ability to manage a set of security context constraints (SCCs) for limiting and securing their cluster. Security context constraints allow administrators to control permissions for pods using the CLI.

SCCs allow an administrator to control the following:

  1. Running of privileged containers.
  2. Capabilities a container can request to be added.
  3. Use of host directories as volumes.
  4. The SELinux context of the container.
  5. The user ID.
  6. The use of host namespaces and networking.
  7. Allocating an ‘FSGroup’ that owns the pod’s volumes
  8. Configuring allowable supplemental groups
  9. Requiring the use of a read only root file system
  10. Controlling the usage of volume types
  11. Configuring allowable seccomp profiles

Continue reading “Understanding OpenShift Security Context Constraints”

Share

Managing temporary files with systemd-tmpfiles on Red Hat Enterprise Linux 7

aarrichi
By Alessandro Arrichiello

Have you ever used a temporary directory? I’m guessing if you use a computer, you’ve used one of these. It’s a core feature of nearly every operating-system.

To ensure system stability, you should always check that filesystems on which a temporary directory resides don’t get full — running out of space can quickly bring your system to a grinding halt.

One method to prevent running out of space could be to place those directories on a dedicated partition, but no matter the solution, it is a best practice to clean those directories periodically, based on your/your app’s needs.

Continue reading “Managing temporary files with systemd-tmpfiles on Red Hat Enterprise Linux 7”

Share