Continue reading Repost – Architecting Containers Part 1: User Space vs. Kernel Space
What are user namespaces? Sticking with the apartment complex analogy, the numbering of users and groups have historically been the same in every container and in the underlying host, just like public channel 10 is generally the same in every unit in an apartment building.
But, imagine that people in different apartments are getting their television signal from different cable and satellite companies. Channel 10 is now different for each person. It might be sports for one person, and news for another.
Continue reading “Repost: What’s Next for Containers? User Namespaces”
Abstract from DevNation 2014: Messaging has become a critical infrastructure component for both developers and systems administrators. Scaling infrastructure in an efficient and manageable way is critical in modern physical, virtual and cloud infrastructures. To provide value to the business, developers and systems administrators must understand technical and business advantages of current and future architectures.
Join Scott McCarty and Scott Cranton as they bring years of experience in building scalable, fault tolerant, distributed systems to the architectural challenges of building durable messaging platforms. Attendees will receive guidance on emerging technologies as well as an understanding of the strengths of current solutions like Red Hat JBoss A-MQ.
Continue reading “DevNation 2014 – Scott Cranton and Scott McCarty – Resilient Enterprise Messaging with JBoss A-MQ”
Docker has quite an amount of buzz around it today because it makes so many things easy that were difficult with virtual machines.
Docker containers makes it easy for Developers, Systems Administrators, Architects, Consultants and others to quickly test a piece of software in a container; much quicker than a virtual machine, and using less resources. The average command in Docker takes under a second to complete.
Continue reading “A practical introduction to Docker containers”
At JUDCon 2013 in Boston, Scott Cranton and I presented a talk entitled Resilient Enterprise Messaging with Fuse & Red Hat Enterprise Linux. This technical article is the follow up work from that presentation.
JBoss A-MQ is built on ActiveMQ which is a robust messaging platform that supports STOMP, JMS, AMQP and modern principals in Message Oriented Middleware (MOM). It’s built from the ground up to be loosely coupled and asynchronous in nature. This provides ActiveMQ with native high availability capabilities. An administrator can easily configure an ActiveMQ master/slave architecture with a shared filesystem. In the future this will be augmented with Replicated LevelDB.
Red Hat Enterprise Linux is the popular, stable and scalable Linux distribution which has High Availability and Resilient Storage add-on support built on CMAN, RGManager, Corosync, and GFS2. High Availability and Resilient Storage expand upon the high availability capabilities built into ActiveMQ and provide a robust, and complete solution for enterprise deployments that require deeper clustering capabilities.
There are two main architectures commonly used to provide fault tolerance to a messaging server. The first is master/slave which is easy to configure, but as it scales, it requires 2X resources. The second is made up of active nodes and redundant nodes. The redundant nodes can take over for any one of the active nodes should they scale. The active/redundant architecture requires more software and more initial configuration, but uses N+1 or N+2 resources as it scales.
This article will explore the technical requirements and best practices for building and designing a N+1 architecture using JBoss A-MQ, Red Hat Enterprise Linux, the High Availability Add-On and the Resilient Storage Add-On.
Continue reading “Resilient Enterprise Messaging with JBoss A-MQ & Red Hat Enterprise Linux”
As I discussed in an article entitled Red Enterprise Linux Release Speed, developers sometimes have a problem with how slow Red Hat’s Enterprise Linux releases new versions of software. Well, the good news is, Software Collections are here. Software Collections provide Red Hat Enterprise Linux users with newer versions of programming languages and server daemons like python, perl, ruby, php, mysql, mariadb, etc.
This is a quick start guide to help you get comfortable with both programming languages and server daemons provided as software collections.
First, add the right channel to your system
rhn-channel -u fatherlinux --add --channel=rhel-x86_64-server-6-rhscl-1-beta
To discover what packages are available, do a quick list, and grep for rhscl.
yum list available | grep rhscl mariadb55.x86_64 1-6.el6 rhel-x86_64-server-6-rhscl-1-beta mariadb55-mariadb.x86_64 5.5.30-9.el6 rhel-x86_64-server-6-rhscl-1-beta mariadb55-mariadb-bench.x86_64 5.5.30-9.el6 rhel-x86_64-server-6-rhscl-1-beta mariadb55-mariadb-devel.x86_64 5.5.30-9.el6 rhel-x86_64-server-6-rhscl-1-beta mariadb55-mariadb-libs.x86_64 5.5.30-9.el6 rhel-x86_64-server-6-rhscl-1-beta mariadb55-mariadb-server.x86_64 5.5.30-9.el6 rhel-x86_64-server-6-rhscl-1-beta mariadb55-mariadb-test.x86_64 5.5.30-9.el6 rhel-x86_64-server-6-rhscl-1-beta ....
Now, let’s install a few interesting packages
Continue reading “Software Collections Quickstart”
The goal of this article is use the OpenShift Platform as a Service (PaaS) as a learning platform for Django. Most of the technical articles out there about running Django on OpenShift assume the user already understands how to administer Django environments and projects. This article is written from the perspective of someone who has done some python programming and wants to learn some Django without doing a bunch of setup work.
Since each OpenShift Gear “…is a container with a set of resources that allows users to run their applications”, a user can ssh in to test, troubleshoot, debug and learn. This turns out to be quite convenient for learning Django.
First, we must deploy an OpenShift application. The deployment is completely automated with the Django Quickstart. Once completed, the web interface will return all of the connection information necessary for Django, Git, and SSH. Estimate 5 minutes.
https://www.openshift.com/quickstarts/django -> Deploy Now