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

Understanding Ansible Tower Isolated Nodes

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)

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

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”

Share

Understanding OpenShift Security Context Constraints

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