Loading...

Follow Red Hat Services Speak on Feedspot

Continue with Google
Continue with Facebook
or

Valid

Disclaimer: the high-level architecture solution and the related demo code is an opinionated implementation to solve the problem described here. The author believes that DevOps is not about tools and frameworks, but a mindset and cultural change for teams. This is an implementation that aims to help a team on the DevOps journey of increasing shared understanding within traditional Development and Operation teams.

There are some challenges while adopting a PaaS Platform like OpenShift in an organization. Traditional IT teams have operated in silos where responsibilities for different parts of the Product lifecycle were distributed to different teams, for example, a development team and a release or production team. The teams’ domain of knowledge is, traditionally, limited to the activities they perform for their part of the chain of work and communication between these teams lacked flow or was done using ticketing systems that increase handoffs.

There are some reasons why Organizations are adopting/moving to PaaS and Microservices. Increasing Product Team autonomy and agility are some reasons. Red Hat’s OpenShift product and containers, in general, are great solutions to achieve this speed (by providing the Developer Teams with the freedom to build, test and deploy their code faster). Tools alone don’t make you “DevOps”, there is still a cultural change required to fully adopt these technologies and many organizations struggle with this process when scaling to multiple Teams and the time to move from Dev to Production comes.

The goal of this article is to:

  • Show how we can use different Red Hat technologies together such as Ansible, Ansible Tower and OpenShift to enable different teams to work as a large long-lived cross-functional Product Team.
  • Help to break the existing walls between traditional IT teams, putting a shared language and a shared framework between these teams, so responsibility for the whole Product lifecycle is shared between all the members of the team.

One of the things we do in the Red Hat Open Innovation Labs is to help Customer Teams to transform themselves through our Residencies. We use Agile as part of the Residency process and use different practices and tools as described here. This post is based on the solutions we have already implemented at multiple Customers demonstrating the “Everything as Code” practice.

As previously described, a typical team moving to a DevOps model while adopting PaaS and Containers is one formed by Development and Operations teams. Development is focused on writing the application code, Operations is focused on managing the platform and at the same time supporting the Development team to build and deploy their code onto the Platform. The issues arise when Operations have no knowledge about how the code has been built or how the application components interact. Supporting these teams at scale becomes a nightmare and the Platform that was chosen to gain agility often ends up having the existing rules used to manage IT applied to it, resulting in an underused platform which is an inhibitor for Agile development.

The following diagram shows one solution to this problem. Using Ansible, Ansible Tower and OpenShift we can develop a framework based on a Self-Service model to put a shared deployment language between product teams and those that provide the platform, this shared language is based on how to build and deploy objects into the platform, which increases shared understanding.

Each bullet point represents a stage in the system. On the first stage (1)(2), a Developer uses Ansible Tower frontend (a custom frontend could be created which interacts with Tower via an API) to self-request the onboarding of the product team and their application/services(s) into the platform. Ansible Tower handles that information and will execute a Workflow Job (3) onboarding the user into the system, creating all the required objects as described here and report back to the user via email.

As part of the Workflow, a GIT repository will be initialized (4), that will include the structure to manage both application source code, OpenShift objects and the Jenkins configuration represented in a ‘Jenkinsfile’ as code. The initial OpenShift configuration created includes 4 different OpenShift projects (5), the ‘CI’ project that will include the Jenkins deployment for the application CI/CD process, and 3 additional projects that will be used for image promotion driven by the end to end Jenkins Pipeline previously created.

A custom Hook will be configured as well into the GIT repository, that will trigger the Jenkins pipeline on every code commit (6). This means that on every change committed to GIT by the Developer Team, the Jenkins Pipeline will not only build, test and deploy the application but also will modify/create any existing OpenShift object defined as code in the GIT repository. As part of the sample code you can see how is this achieved using a Framework developed by the Red Hat CoPs called OpenShift Applier we use at Red Hat Open Innovation Labs with every customer during our Residencies.

From now on, the GIT repository will be the only entrypoint for the Development Team (7). This will add 2 main advantages:

  • Both Devs and Ops have now a shared framework and shared language on the objects (defined as code as we can see here) that are deployed into the Cluster – increasing shared understanding from both sides
  • Every single object deployed into the Cluster including the build Pipeline is now represented as code in a GIT repository – adding the capability to recreate all the content from scratch in case of Cluster failure or recreate objects in a different Cluster for testing or any other purpose with the only effort of changing the destination OpenShift API.

 
Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Join the Red Hat Learning Community
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

This post was originally published on the ETI blog here.

So – you want to stop your OpenShift cluster? There are many reasons why you may want to stop your OpenShift cluster. Maybe you have an annual disaster recovery test where you shut down a whole datacenter. Perhaps you want to do some maintenance to your infrastructure or the hypervisor or storage that your cluster is hosted on. It’s not an uncommon to need to be able to do this, so I have collated some of the best practices I have experienced across a multitude of environments, both large and small.

Here is the process that I recommend to use as a best practice in order to stop and start your OpenShift cluster(s). Following this process will give you the best chance of a trouble free maintenance window. As with all things, you should exercise care with this process on your important clusters. Try it on an unimportant environment first and see if it is a good fit for you.

Important: This process will cause an outage to any application workload running on the cluster until the cluster is fully started. The cluster itself will be unavailable until manually started. Care should be taken to run this process only on appropriate environments. It is recommended to have backups available of your environment.

 

Stopping your cluster

Stopping a cluster is a relatively straight forward process. The real difficulty is always related to the workload on top of the cluster. You should also ensure that  you have the ability to roll things back if anything goes wrong. This means that you need to be confident in your ability to rebuild a cluster; have a mature, tested backup process in place (you’re doing this anyway, right?) and have an understanding of the workload you are running.

Know your state

The first thing I like to do is to ensure that I know what state my cluster is in before I carry out this type of activity. I want to know what namespaces I have ( oc projects ), what state pods are in ( oc get pods --all-namespaces ) and what state my nodes are in ( oc get nodes --show-labels ). Knowing what is working and what isn’t is important when it comes to knowing what ‘the same as before’ looks like after you have started the cluster again.

You should resolve any issues in the cluster before proceeding– For example oc get nodes should show that all nodes are ready. Guidance around more in-depth checks can be found in the documentation.

Tip: If node configurations are not properly configured, labels will not be correctly applied. Ensure that node configs are properly applied in order to retain node labels during restart activity. Refer to the documentation for more information.

Plan for failure

Next, cut a backup of your cluster. You are probably doing this on a regular basis but if you’re not you should take a look at tooling like https://velero.io/ which helps you to regularly snapshot your cluster state and persistent storage and ship it to one of a number of storage targets such as S3. If you want to roll your own, you can refer to the documentation which details what you need to capture as part of an environment backup.

Tip: Powering nodes off as opposed to a graceful shutdown of a running cluster is a bad idea, as applications and services may be left in an inconsistent state. Ensure that you have appropriate backups in place according to the documentation.

If the answer to the question ‘can I put it all back if I need to?’ isn’t yes, then don’t continue.

Stop your applications

Now that we know what our cluster looks like and we know that we can restore in the event of any issues, we can stop our application workload. Ensuring that application workload is stopped in a controlled manner helps us to avoid data loss.

Tip: Care should be taken with application workloads to ensure that they are stopped gracefully to prevent accidental data loss. Data consistency is important!

Your first option is to you scale down all of your deployment configs so that no application pods are running. You may want to consider idling pods as a way to stop workload dynamically, or crafting Ansible playbooks in order to restart the correct number of replica’s when we start the cluster later. Either way you will need to know how many replica’s you are putting back.

Your second option is that you may wish to drain the workload from all worker nodes rather than stopping all applications individually in order to ensure application consistency. In this case you would need to:

1a.  Cordon all of your worker nodes to prevent new pods from starting or moving oc adm cordon <node>. Refer to the documentation about scheduling nodes.

1b.  Drain all of your worker nodes using something like: oc adm drain <node> --ignore-daemonsets --force --grace-period=30 --delete-local-data. This forces pods to stop, ignores any daemonsets that are running on the nodes, enforces a graceful termination period of 30s for pods to stop gracefully and removes any pods with local ephemeral data.

It is recommended that you review the options for draining nodes in the documentation.

Your third option is to gracefully shutdown your worker nodes without draining your application workload. This approach works well if you don’t have any stateful services like databases or you have designed your application to tolerate failure. A graceful shutdown causes your application processes to stop as part of a system shutdown. Eventually any processes which have not stopped gracefully will be forced to terminate. Pods that were running at the time a cluster stops will start again on the worker that it was last scheduled on. This enables workload to start again in-place during a cluster startup quickly after an event such as a power loss.

Stop your cluster

Tip: Block storage volumes which have been dynamically provisioned through a cloud provider like AWS EBS or VMWare vSphere will remain attached to any nodes where pods were running with persistent storage unless that workload is stopped.

  1. Gracefully shutdown all worker nodes – For example: shutdown -h now. All workers need to be shutdown together or cordoned, otherwise OpenShift may attempt to reschedule workload.
  2. Gracefully shutdown all Infra nodes – For example: shutdown -h now.
  3. Gracefully shutdown all masters – For example: shutdown -h now.
Starting your cluster

Bringing the cluster back up is much more simple than the shutdown procedure. You just have to start nodes in the right order for the best results.

Tip: Additional guidance on the subject of checking cluster health can be found as part of the day2 operations guide

Start your master nodes

Once they have booted we can check that they are healthy using oc get nodes – all nodes should be in a ready state before continuing on to your infra nodes.

Start your infra nodes

Once your infra nodes have booted you can ensure that infra nodes are showing in a ready state, and that oc get pods –all-namespaces shows the logging, metrics, router and registry pods have started and are healthy.

Start your worker nodes

Once your worker nodes have booted you can ensure that all nodes are showing in a ready state with oc get nodes. Refer to the health check documentation for a more in-depth set of checks.

Start your applications

Now that your cluster has started and you’ve proven that it is healthy, you can now start your application workload. If you chose to simply shutdown your worker nodes without draining workload then your applications will be restarting on the nodes they were previously located, otherwise you will need to increase the number of replica’s or uncordon nodes depending on the approach you took.

Finally, check that your application pods have started correctly oc get pods --all-namespaces and perform any checks that may be necessary on your application to prove that it is available and healthy.

Useful links:
    1. OpenShift Day 2 Operations guide: https://docs.openshift.com/container-platform/3.11/day_two_guide/environment_health_checks.html
    2. Red Hat verified solution for shutting down or restarting a cluster. https://access.redhat.com/solutions/3499881
    3. Documentation about scheduling nodes: https://docs.openshift.com/container-platform/3.11/admin_guide/manage_nodes.html#marking-nodes-as-unschedulable-or-schedulable
    4. Documentation about draining nodes https://docs.openshift.com/container-platform/3.11/admin_guide/manage_nodes.html#evacuating-pods-on-nodes
    5. Documentation about idling pods: https://docs.openshift.com/container-platform/3.11/admin_guide/idling_applications.html
    6. Documentation regarding cluster backups https://docs.openshift.com/container-platform/3.11/day_two_guide/environment_backup.html
    7. Documentation about how to label nodes https://docs.openshift.com/container-platform/3.11/admin_guide/manage_nodes.html#modifying-nodes
    8. Documentation covering cluster health checks https://docs.openshift.com/container-platform/3.11/day_two_guide/environment_health_checks.html
    9. Velero project website: https://velero.io/

Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Join the Red Hat Learning Community
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

With the release of Red Hat Enterprise Linux 8, the Training and Certification team also announced its launch of offerings to coincide with the new version. Courses and exams contributing to the Red Hat Certified System Administrator (RHCSA) title are available on redhat.com and in the Red Hat Learning Subscription.

Skill in system administration of Red Hat Enterprise Linux systems is a core competency in the modern data center. Linux is an integral technology enabling the hybrid cloud architecture, across physical servers, virtual machines, private and public cloud computing infrastructures, and in containers. Red Hat Enterprise Linux is the de facto standard Linux distribution across all these architectures.

As you seek to move to containers and a hybrid cloud architecture, core Linux administration skills remain increasingly necessary because they provide the fundamental foundation for container adoption, as well as technologies like Kubernetes, and are enabling skills for adoption of DevOps practices.

Through this curriculum, you will understand the core skills needed to be a bridge to the contemporary data center, containers, and cloud computing technologies, and become more valuable to your organization.

We invite you to take a look at our Red Hat Learning Subscription and start taking advantage of these new courses today! If you are unsure where to begin your RHEL 8 journey, take our Linux skills assessment to receive our recommendation.

Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Join the Red Hat Learning Community
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Thank you to everyone who attended Summit 2019 in Boston and engaged with Red Hat Services! Our wonderful customers, partners, and attendees fostered engaging conversations with our team. We appreciate each of you who sought us out in the Customer Success Zone and the Partner Success Lounge to ask thoughtful questions, learn more about enabling yourself to adopt Red Hat technologies, and participated in our events. For those who weren’t able to connect with us, here’s what you missed: 

GLOBAL SERVICES EXPAND POSSIBILITIES THROUGH COLLABORATION

Red Hat senior vice president and general manager of Global Services John Allessio was joined on stage by representatives from ExxonMobil, Lockheed Martin, and Volkswagen to share their stories about engaging with Red Hat Services. Audrey Reznik, Data Scientist, and Austen Smack, Container platforms product owner, from Exxon shared how their company embraced containerization technology to solve the world’s most difficult energy challenges. Through the power of our Services, this organization helped their data scientists, engineers, and geoscientists more than 130 teams globally change the way they work. Lockheed Martin’s Vice president of product development for F-16/F-22 integrated fighter group Michael Cawood and his team shared how they brought new capabilities to the U.S. Air Force’s fleet of F-22 Raptor fighter jets. Their work with Red Hat Open Innovation Labs enabled them to modernize the application development process which transformed the company’s culture, processes, and technologies, and also made them rethink how their teams function. Michael Denecke, head of test technology at Volkswagen, also shared his company’s experience with Open Innovation Labs and how they utilized this resource to develop a new way to test car features. The team created a customized test bench that connected the real test bench world with the virtual world – all in 3 months.

TRAINING AND CERTIFICATION

The Training and Certification team was located in the Customer Success Zone sharing information about the Red Hat Learning Subscription, changes to our Red Hat Certified Engineer (RHCE) program, Red Hat Learning Community, and more. Many visitors received an in depth demonstration of the RHLS platform, as well as, guidance on receiving a free trial. As always, Summit wouldn’t be complete without swag! Attendees who visited our booth received picnic blankets, notebooks, and coffee mugs.

Power Training

Over 250 students signed up to take our courses and exams this week. We offered curriculum across a variety of our products and technologies, with course titles including: Red Hat Enterprise Linux 8 Preview, Introduction to Containers, Kubernetes, and OpenShift Container Platform, Automation with Ansible, and more. Upon arrival all attendees received hard copy course books, instructor led training, and a 30-day Red Hat Learning Subscription with full access to all of our content.  We also held a Power Training Reception complete with cocktails and appetizers. 

Red Hat Certified Professional of the Year

Jason Hiatt from One Main Financial was named the 2019 Red Hat Certified Professional of the Year! Congratulations to Jason on his outstanding accomplishments, including his incredible community involvement, success OpenShift project, and dedication to continuous innovation through learning. Jason (left) was recognized on stage by Red Hat executive vice president and president, Products and Technologies, Paul Cormier (right) during his keynote speech on Wednesday, May 8th.

Red Hat Certified Professionals Reception

We love to celebrate and honor our dedicated RHCPs! Every year, we host a celebration to thank and showcase them for their outstanding achievements. On Tuesday, May 7th we rented out the Laugh Boston space for karaoke, food, and drinks. Party goers enjoyed a taco station with chefs preparing each dish and, of course, it wouldn’t be Boston if we didn’t serve Sam Adams on draft.  

Red Hat Enterprise Linux 8

With the exciting release of Red Hat Enterprise Linux 8, our curriculum team simultaneously launched our Linux offerings based on this new version. Through this curriculum, you will understand the core skills needed to be a bridge to the contemporary data center, containers, and cloud computing technologies, and become more valuable to your organization.

Not sure where to begin with RHEL 8? Take our Linux skills assessment to find out where we recommend beginning your learning journey.

RED HAT CONSULTING

Discovery Session Theater

At this year’s Red Hat Summit in Boston we continued our Red Hat Consulting Discovery Session series for the fourth year in a row. This year the Red Hat Consulting Discovery Session Theater was located in the Ecosystem Expo a part of the Customer Success Zone, opening the space up to walking traffic, but also providing an enclosed theater for customer conversations.

Attendees were able to join Red Hat experts for interactive discovery sessions featuring solution-focused discussions that impact their businesses. During this time, consultants dove deep into today’s critical technology implementations and offered best practices in an interactive whiteboarding environment. This year we were happy to feature global representation as well as our first ever session delivered entirely in Spanish! The sessions are listed below:

  • People first, digital second: Using open principles to drive transformation at Heritage Bank
  • Digital Nudge: How automation, machine learning, artificial intelligence, and more shape our digital decisions
  • Lean UX in action: Learn, prototype, and measure together
  • How Volkswagen used microservices and automation to develop self-service solutions
  • Container adoption at scale: Metrics-driven framework and other lessons learned
  • OpenShift DevSecOps: Securing your enterprise for tomorrow, today
  • To the Edge and Beyond: Network Automation for Telecommunications
  • 4 ways to jump start an open source & agile automation culture
  • The road to Red Hat Enterprise Linux 8: Best practices for optimizing your operating system
  • Adoptando Red Hat Enterprise Linux 8: Las mejores practicas para optimizar tu Sistema Operativo
  • A DevOps survival guide: Small changes lead to big results
  • Monoliths in OpenShift: Application onboarding strategies for containers

Red Hat Open Innovation Labs

With the third anniversary of its founding quickly approaching, Red Hat Open Innovation Labs was integrated into several different activities at this year’s Red Hat Summit.

Our Open Innovation Labs coloring wall made its debut at the event as a part of the Customer Success Zone in the Ecosystem Expo. Benefiting a local charity, Rise Against Hunger, attendees colored in a mural of the Mobius Loop as well as interacted with and learned about open practices used every day in Labs.

In addition to this presence on the Expo floor, there were also ancillary events hosted in the Open Innovation Labs space in the Boston office. A breakfast event kicked off the week the morning before Executive Exchange, and featured a panel discussion with customers like NASA, BlueCross BlueShield NC, among others, and an interactive tour. After, there was a cocktail event on Wednesday evening, promoting the Labs way of working through cocktail creation.

PARTNERS

Red Hat Partner Success Lounge

Attendees stopped by the Red Hat Partner Success Zone booth to learn about the newest partner program offerings through Red Hat Partner Connect, such as our newly available partner training and enablement on Red Hat Enterprise Linux 8 and Red Hat OpenShift 4. Red Hat partners were given exclusive swag, a Red Hat branded hammock! 

Build SkillsGain industry-recognized skills through hundreds of on-demand courses and accreditations.

Partner with usJoin our trusted ecosystem of industry-leaders.

Go to MarketDiscover how you can make greater market impact with Red Hat.

Discover SolutionsBuild and improve customer relationships with Red Hat solutions.

Certify Your ProductsTest and certify your products on the Red Hat portfolio

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Previously published on She ITs and Giggles.

Overview

Frequently when I’m on site I am not directly asked but I am expected to provide answers to my customers how to get the best use of a technology. In this post I’m examining a recent scenario around providing structure around deploying OpenShift in order to provide a collaboration environment that would aide the use of this technology. We were also deploying OpenShift but writing about OpenShift deployment is a well covered subject across the board.

Background

I’ve recently visited a customer that wished to containerise the world and provide to their developer community a Container As A Service (CaaS) – a single enterprise kubernentes cluster that would allow groups of developers to develop and deploy, as well as an Enterprise Kubernetes cluster As A Service (KaaS) offering – a series of clusters that would be ordered on demand by different management chains and in different security groups. Although I think the first one is easy to do and would fit many use cases, the second one is definitely more complex; big vendors and service companies still struggle in updating and maintaining multiple clusters of Kubernetes distributions especially when those distributions have massively different configurations.

When I first went on site, I realised that I was in London and my primary contacts were working remotely. This is quite uncommon for consulting engagements but it was a common theme for the organisation I was working with: distributed teams with minimal travel budgets. I need to pick my fights as to what I can change, so I set course to meet my primary contacts in a central European city that would suit them to organise a series of workshops that would help us agree on ways of working, tools, technologies, architecture etc.  Even if I was working on this project remotely for a few weeks this was a major breakthrough to the pace of work. This was a highly effective method of getting to know and trusting each other. Other than time and experience in the field, a few techniques that I used played major role in that too.

Using Open Practice Library practices in a distributed team

At the time, I had recently finished a precursor of the current  DevOps Culture and Practice Enablement – DO500  course  and I was eager to put what I had learned in practice. I thought that these methods are always effective and able to bring people together talking about the right things.

When I arrived in the mutually agreed location,  I was given a list of objectives to help the organisation deploy OpenShift Container Platform (OCP) as a service. We started first discussing why we were trying to achieve what we were trying to achieve and what success would look like using a Start At The End method. This was very useful to give us context and direction as we wanted to make sure that the business would get the most of this. It made us focus on what the end goal is: user (developer) satisfaction by creating seamless integration with current customer systems, ease of testability and  and engagement with the product.

We then followed on agreeing a list of things we would continue doing to make sure that collaboration and focus doesn’t wane; we built our foundation:

  • We decided to use pair programming techniques whereby having two people delivering a feature and many when learning something new in the platform. When using this in delivering features to the platform we ensured that knowledge is distributed across the team. This also enabled a constant channel of communication being open between distributed team members. Old fashioned video conferencing and screen sharing was sufficient at the time but we later explored tmuxconfiguration for shared command line access to machines. Anything beyond that was a struggle regarding pair programming tooling as the environment was quite locked down to allow the live share functionaly of VSCode or something similar.
  • It was important for us to ensure that everything we did was repeatable so all the changes we wanted to do whether it was a configuration change or a build change or deploying new servers we codified first. We mainly used Ansible playbooks or Jenkins pipelines and followed the everything as code practice. We used git  which made our code versionable  and when we released a  new stable version of the platform we tagged that to indicate that point. We could always revert to a working version. This helped us a few times especially at the beginning when we needed to spin a new cluster very quickly to test new functionality.
  • We agreed on a set of rules we’d all abide by: including core hours of work, remote-scrum times,  and potentially a sense of humour. We wrote our social contract and signed it and then transcribed it to our wiki. This gave us an understanding of when  and how it was best to collaborate even with our different cultural backgrounds and timezones.

I’ve seen a few of these deployments in the past and one of the main success or failure criteria that I have seen is development and business engagement. Therefore, it was important to ensure that developers were engaged as much as possible to use this platform to test and develop.

Tweaks

From the initial set of practices we used to collaborate we found that they worked quite well but needed a few modifications and additions. Below are things that we changed or would have liked to have changed:

  • OpenShift  and Kubernetes in general is a fast moving platform, while learning about all the new components, integrations and modifications, it was important to educate our users too. We set up time during our days to absorb new material in the community by reading blog posts, following tutorials and adapting some of it for consumption of our users. This is something we then added to our social contract.
  • Empathy mapping and user interviews for increasing user engagement was something we were all interested in and it was a key factor in getting the platform moving forward. We wanted to ensure that new users of any container technology would first try and potentially succeed with OpenShift. We came up with a list of teams that were aiming to create cloud-native workloads or could benefit from a modernisation and came up with a list of questions to understand their current frustrations when developing and constraints. This gave us a direct line with our main users after we started enabling features for the platform.
  • Using principles such as everything as code is great 80% of the time for everything that is well understood. However, there was a good 20% that the value of automating something needed to be proven by testing a change worked manually first. This 20% gap was later minimised by introducing automated tests as part of building a new cluster that would give us an answer as to if our changes were sane and worked.
  • Not all scrum events worked well in this distributed team. Our daily standup ended up in a debugging session more often than not. Although this was useful I feel like we were missing the point in focusing time a bit better. I understand why too; the setting was exactly the same we were on a video call all day to each other.  It improved a little bit after one suggestion: to stand up during our phone call. However, I feel like it would have been much easier to have a scrum master to enable us.
  • Visualising our workload was something that we had to do using digital tools like wikis and digital kanban boards. However, having physical copies of our social contract and actual boards to write on would have helped massively in actually re-focusing every time we looked around or went for a coffee. Space was something that wouldn’t allow us to do that but I believe that it would bring even better results.
Next Time

These are the things I would do differently next time.

I would love to push that initial collaboration meeting a few weeks forward. This was the catalyst in actually working better together. It created connections that are so difficult to forge over the phone or video conferencing and a lot of trust.

Product owner involvement was not as high as I expected and delegated to the team. Although this was good as it gave us more power, creating the initial connections to the developers was slow and frustrating. If I were to do this again I would stress even more how important time with the team and the developers would be.

Takeaways

So far, with the practices used above, I’ve seen not only successful deployment and use of OpenShift but a clear shift as to how people talk to each other and want to contribute to this project. Whether it’s a small company, or a global supertanker of an organisation, everyone wants to improve their ways of working. This was keenly felt here. These practices are easy to try but they take discipline and good humour to continue especially in the context of widely distributed teams. I would thoroughly recommend trying them and reporting back on which ones you picked and why.

References

If you want to learn more about practices used in this blog post visit https://openpracticelibrary.com.

If you are interested in OpenShift and learning more about the technology visit https://docs.openshift.com.

If you are interested in automation around self-created IaaS and OpenShift  follow the CASL project. This was used as an upstream OpenShift deployment tool with pre-and post installation hooks and upstream changes were made to ensure the the community would  be able to work around the customer’s required changes.

Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Overview

Frequently when I’m on site I am not directly asked but I am expected to provide answers to my customers how to get the best use of a technology. In this post I’m examining a recent scenario around providing structure around deploying OpenShift in order to provide a collaboration environment that would aide the use of this technology. We were also deploying OpenShift but writing about OpenShift deployment is a well covered subject across the board.

Background

I’ve recently visited a customer that wished to containerise the world and provide to their developer community a Container As A Service (CaaS) – a single enterprise kubernentes cluster that would allow groups of developers to develop and deploy, as well as an Enterprise Kubernetes cluster As A Service (KaaS) offering – a series of clusters that would be ordered on demand by different management chains and in different security groups. Although I think the first one is easy to do and would fit many use cases, the second one is definitely more complex; big vendors and service companies still struggle in updating and maintaining multiple clusters of Kubernetes distributions especially when those distributions have massively different configurations.

When I first went on site, I realised that I was in London and my primary contacts were working remotely. This is quite uncommon for consulting engagements but it was a common theme for the organisation I was working with: distributed teams with minimal travel budgets. I need to pick my fights as to what I can change, so I set course to meet my primary contacts in a central European city that would suit them to organise a series of workshops that would help us agree on ways of working, tools, technologies, architecture etc.  Even if I was working on this project remotely for a few weeks this was a major breakthrough to the pace of work. This was a highly effective method of getting to know and trusting each other. Other than time and experience in the field, a few techniques that I used played major role in that too.

Using Open Practice Library practices in a distributed team

At the time, I had recently finished a precursor of the current  DevOps Culture and Practice Enablement – DO500  course  and I was eager to put what I had learned in practice. I thought that these methods are always effective and able to bring people together talking about the right things.

When I arrived in the mutually agreed location,  I was given a list of objectives to help the organisation deploy OpenShift Container Platform (OCP) as a service. We started first discussing why we were trying to achieve what we were trying to achieve and what success would look like using a Start At The End method. This was very useful to give us context and direction as we wanted to make sure that the business would get the most of this. It made us focus on what the end goal is: user (developer) satisfaction by creating seamless integration with current customer systems, ease of testability and  and engagement with the product.

We then followed on agreeing a list of things we would continue doing to make sure that collaboration and focus doesn’t wane; we built our foundation:

  • We decided to use pair programming techniques whereby having two people delivering a feature and many when learning something new in the platform. When using this in delivering features to the platform we ensured that knowledge is distributed across the team. This also enabled a constant channel of communication being open between distributed team members. Old fashioned video conferencing and screen sharing was sufficient at the time but we later explored tmuxconfiguration for shared command line access to machines. Anything beyond that was a struggle regarding pair programming tooling as the environment was quite locked down to allow the live share functionaly of VSCode or something similar.
  • It was important for us to ensure that everything we did was repeatable so all the changes we wanted to do whether it was a configuration change or a build change or deploying new servers we codified first. We mainly used Ansible playbooks or Jenkins pipelines and followed the everything as code practice. We used git  which made our code versionable  and when we released a  new stable version of the platform we tagged that to indicate that point. We could always revert to a working version. This helped us a few times especially at the beginning when we needed to spin a new cluster very quickly to test new functionality.
  • We agreed on a set of rules we’d all abide by: including core hours of work, remote-scrum times,  and potentially a sense of humour. We wrote our social contract and signed it and then transcribed it to our wiki. This gave us an understanding of when  and how it was best to collaborate even with our different cultural backgrounds and timezones.

I’ve seen a few of these deployments in the past and one of the main success or failure criteria that I have seen is development and business engagement. Therefore, it was important to ensure that developers were engaged as much as possible to use this platform to test and develop.

Tweaks

From the initial set of practices we used to collaborate we found that they worked quite well but needed a few modifications and additions. Below are things that we changed or would have liked to have changed:

  • OpenShift  and Kubernetes in general is a fast moving platform, while learning about all the new components, integrations and modifications, it was important to educate our users too. We set up time during our days to absorb new material in the community by reading blog posts, following tutorials and adapting some of it for consumption of our users. This is something we then added to our social contract.
  • Empathy mapping and user interviews for increasing user engagement was something we were all interested in and it was a key factor in getting the platform moving forward. We wanted to ensure that new users of any container technology would first try and potentially succeed with OpenShift. We came up with a list of teams that were aiming to create cloud-native workloads or could benefit from a modernisation and came up with a list of questions to understand their current frustrations when developing and constraints. This gave us a direct line with our main users after we started enabling features for the platform.
  • Using principles such as everything as code is great 80% of the time for everything that is well understood. However, there was a good 20% that the value of automating something needed to be proven by testing a change worked manually first. This 20% gap was later minimised by introducing automated tests as part of building a new cluster that would give us an answer as to if our changes were sane and worked.
  • Not all scrum events worked well in this distributed team. Our daily standup ended up in a debugging session more often than not. Although this was useful I feel like we were missing the point in focusing time a bit better. I understand why too; the setting was exactly the same we were on a video call all day to each other.  It improved a little bit after one suggestion: to stand up during our phone call. However, I feel like it would have been much easier to have a scrum master to enable us.
  • Visualising our workload was something that we had to do using digital tools like wikis and digital kanban boards. However, having physical copies of our social contract and actual boards to write on would have helped massively in actually re-focusing every time we looked around or went for a coffee. Space was something that wouldn’t allow us to do that but I believe that it would bring even better results.
Next Time

These are the things I would do differently next time.

I would love to push that initial collaboration meeting a few weeks forward. This was the catalyst in actually working better together. It created connections that are so difficult to forge over the phone or video conferencing and a lot of trust.

Product owner involvement was not as high as I expected and delegated to the team. Although this was good as it gave us more power, creating the initial connections to the developers was slow and frustrating. If I were to do this again I would stress even more how important time with the team and the developers would be.

Takeaways

So far, with the practices used above, I’ve seen not only successful deployment and use of OpenShift but a clear shift as to how people talk to each other and want to contribute to this project. Whether it’s a small company, or a global supertanker of an organisation, everyone wants to improve their ways of working. This was keenly felt here. These practices are easy to try but they take discipline and good humour to continue especially in the context of widely distributed teams. I would thoroughly recommend trying them and reporting back on which ones you picked and why.

References

If you want to learn more about practices used in this blog post visit https://openpracticelibrary.com.

If you are interested in OpenShift and learning more about the technology visit https://docs.openshift.com.

If you are interested in automation around self-created IaaS and OpenShift  follow the CASL project. This was used as an upstream OpenShift deployment tool with pre-and post installation hooks and upstream changes were made to ensure the the community would  be able to work around the customer’s required changes.

Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

The Training and Certification organization is gearing up for Red Hat Summit 2019 in Boston! Stop by our booth space to learn about the countless innovations we developed over the past year, new offerings, updates to our certification programs, and more. Visit us to learn about the exciting new releases and events happening next week!

Where to find us

Our team is located in the Customer Success Zone in the Ecosystem Expo Hall of the Boston Convention and Exhibition Center.

What we have to offer

The Training + Certification group has information on obtaining a free trial of our Red Hat Learning Subscription, along with a new Developer tier added to our portfolio. We also can’t wait to share exciting announcements about upcoming training offerings on new product versions. The Red Hat Certified Professional of the Year will also be announced on stage and this award winner’s outstanding accomplishments will be publicly celebrated. Attendees can expect to learn more about the success and utilization of the Red Hat Learning Community.  

Events we are hosting

Monday, May 6th

BCEC Meeting Level II | 7:30 a.m.-5:00 p.m. EST
Power Training begins as students undergo rigorous, condensed training offerings and put their skills to the test with certification exams. All attendees receive a trial of our basic Red Hat Learning Subscription upon completion. Reserve your spot today!

BCEC Meeting Level II | 8:00 a.m.-5:00 p.m. EST
The Red Hat Learning Community is hosting an on-site photo activation booth. Whether you are already active in this platform or newly signed up, you will be able to get your photo taken and customize your avatar.

BCEC Meeting Level II | 5:00 p.m.-6:30 p.m.
On Monday night, our team will be hosting a Power Training Reception after classes and exams conclude for the day. All students completing one of our offerings during Summit are welcome to attend this cocktail hour with light appetizers.

Tuesday, May 7th

Laugh Boston | 8:00 p.m.-10:00 p.m. EST
Tuesday evening we will host an exclusive Red Hat Certified Professional Reception. All RHCPs with current certifications are welcome to attend this event at Laugh Boston with cocktails and snacks. You can pick up your certification ribbon from the Certification Help Desk, located on Level 2 East.

Wednesday, May 8th

BCEC Hall C | 3:00 p.m. EST
During Paul Cormier’s keynote speech, our Red Hat Certified Professional of the Year is being recognized! Watch as the skills and accomplishments of this incredible recipient are shared on stage.

Become a Red Hat Certified Professional
BCEC Meeting Level II | 8:00 a.m.-11:00 a.m. or 12:30 p.m.-3:30 p.m. EST
Get certified after taking our Red Hat Certified System Administrator (RHCSA) exam (EX200) or Red Hat Certified Specialist in Ansible Automation exam (EX407). Seats are limited, add one of our exams to your Summit pass!

Thursday, May 9th

Get Certified
BCEC Meeting Level II | 8:00 a.m.-11:00 a.m.
Become a Red Hat Certified Professional after passing our Red Hat Certified Engineer (RHCE) exam (EX300) on site. Reserve your spot today.

Follow us on Twitter and Facebook or search #RHSummit to get the latest updates onsite. We can’t wait to see you in Boston!

Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Red Hat Services Speak by Walter Bentley, Senior Manager For .. - 1M ago

Every solution starts with sharing a problem. At Red Hat, when we talk about “open source,” we’re talking about a proven way of collaborating to create technology. The freedom to see the code, to learn from it, to ask questions and offer improvements. This is the open source way. However, bringing together people in your organization to collaborate is often easier said than done.

At Red Hat, we’ve created “Communities of Practice” (CoP) to help our own people collaborate, especially on new and emerging technologies–including automation.

What is a CoP?

At its root, a community of practice is a collection of individuals, whether it be consultants, solution architects, or members of business units coming together to share ideas, content, experiences, questions, and best practices around a particular topic.

How do you get started?

  • Bring people together: Not just virtually. When people come together in person, they not only share ideas, but make them actionable.
  • Develop timelines: Make a very clear timeline as to when this incubation period will begin and end and the goals you’ll accomplish during that time.
  • Set success criteria: In the beginning, define what success looks like for your community of practice.
  • Content, content, content: You must have content to attract members, right? Document your content and create artifacts that people can learn from.

How do you get people to participate?

  • Cast a wide net for launch: Promote it via multiple avenues, not just via email. Share it on team calls, mobile apps, meeting invites, etc.
  • Lurk, consume, contribute: This is a natural progression of behaviors for new members to a CoP. Keep an eye out for these behaviors in your new members and encourage them to progress to where they feel comfortable to contribute. If you leverage a CoP as an avenue for mentoring and internal enablement, you will also find that adoption will be a lot quicker
  • Invite someone important: Inviting someone important that’s part of your organization to speak at your launch meeting will also just be an additional way to attract individuals to your CoP.

How do you grow the community?

You’ll need all levels of your management to buy in to the fact that you’re trying to stand up this community of practice. Be persistent, creative, patient, and resilient.

If you’re interested in learning more about how you can get a jump start at this open source way of working, join myself along with Vikram Nayaran and Phyllis Westerman at Red Hat Summit where we’ll discuss 4 ways to jump start an open source & agile automation culture.

Connect with Red Hat Services

Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Join the Red Hat Learning Community
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Reference Architecture

This diagram represents the reference architecture for a full high availability and disaster recovery solution. This solution can be individually tailored to address a single availability solution. For example, if only disaster recovery is needed the configuration supports exclusion of the HA replica.

High Availability

Ansible Tower clustering provides increased availability by distributing jobs across nodes in a cluster. A failure of a single node results in reduced capacity in the cluster. The database remains a single point of failure in a cluster. If the the database becomes unavailable the cluster will also become unavailable. This configuration provides for a replica database (HA Replica) in the primary cluster datacenter, which can be transitioned to primary. Although not completely automated, this provides for faster recovery in database outage scenarios.

NOTE: In the future this feature will delivered and supported by a third party.

HA Failover HA Failback

Disaster Recovery

Ansible Tower clusters are not recommended to span datacenter boundaries due to latency and outage concerns. In the event of a total datacenter failure Ansible Tower would become unavailable. The Ansible Tower disaster recovery approach allows for failover to pre-provisioned resources in a secondary datacenter. The database in the secondary datacenter configured as a warm standby/replica of the database in the primary datacenter. During a failover, Ansible Tower is installed onto the pre-provisioned nodes and pointed to the replica database (promoted to primary)

DR Failover

DR Failback

Streaming Replication

PostgreSQL provides built in mechanisms to achieve increased availability. The use of warm standby or replica databases allows for simple and fast failover in recovery scenarios.

Configuration Assumptions/Prerequisites
  • all Ansible Tower machines specified in inventory are pre-provisioned with authentication mechanism known (password, SSH keys)
  • Ansible control machine (RHEL 7 or CentOS) available and configured with Ansible 2.7+
  • if not running as root and need to use privilege escalation (eg sudo) you need to set it up in the inventory (ansible_become=true)
  • If there is no connectivity to the internet the bundle installation media will need to be placed in the tower_installer directory. Please ensure the bundle is available before preceding.
  • The Ansible Tower installation inventory for each configuration will need to be defined.
  • This toolkit and the playbook suite is meant to be run by a one user at a time and one playbook at a time. For example, do not try running multiple instances of the tower-setup-replication.yml playbook from the same playbook_dir. Issues can arise because a dynamic inventory script is used with a tmp file indicating which file to load. This mechanism allows to effectively change the inventory during playbook execution.
Setup
  1. Clone this repository to the configure Ansible control machine and enter directory
git clone ssh://git@gitlab.consulting.redhat.com:2222/towerrescue/ansible_tower_setup.git
cd ansible_tower_setup
  1. Create a directory for your Tower installation inventories. Create the appropriate inventory_pm, inventory_ha and inventory_dr Tower installation inventory files in the directory. Examples are provided in the inventory_dr_static and inventory_ha_dr directories of this repository.

Some points to note about your Ansible Tower inventory files:

  • Each inventory represents a separate configuration for Tower (primary, HA, DR)
  • You must define a primary inventory(inventory_pm) along with one or both of the HA inventory(inventory_ha) and DR inventory(inventory_dr)
  • There should be no overlap between primary/HA and disaster recovery instance groups, include the default towerinstance group across inventory files, This goes back to the discussion above that instance groups cannot span datacenters. Isolated instance groups can be repeated if you with to utilize existing isolated nodes.
  • The database and database_replica group membership should be unique across all inventory files. The database group should have only one database and is the database in use the the given configuration. The database_replica groups contain the streaming replicas to be configured.
  • If an external database team is managing the Ansible Tower database and handling the replication and failover, the database_replica group can be excluded and the tower_db_external (explained below) to skip any replication configuration
  • The example inventory files show various configurations for setting up replication in a failover scenario.
    • The HA inventory file, used in HA failover, has streaming replication configured back to the original master and DR database. This is optional but in order to ‘failback’, replication to the original master must be re-enabled.
    • The DR inventory file, used in DR failover, has streaming replication configured back to the original master and leaves replication to the HA database. This is optional but in order to ‘failback’, replication to the original master must be re-enabled.

Examples

inventory_ha_dr/inventory_pm

[tower]
towervm1 ansible_ssh_host="10.26.10.50"

[database]
towerdb1 ansible_host="10.26.10.20"

[database_replica]
towerdb2 ansible_host="10.26.10.21" pgsqlrep_type=local
towerdb3 ansible_host="10.26.10.22" pgsqlrep_type=remote

[database_all:children]
database
database_replica

[database_all:vars]
pgsqlrep_password=password4

[all:vars]
<<CLIPPED>>
pg_host='10.26.10.20'
<<CLIPPED>>

inventory_ha_dr/inventory_dr

[tower]
towervm2 ansible_host="10.26.10.51"

[database]
towerdb3 ansible_host="10.26.10.22"

[database_replica]
towerdb1 ansible_host="10.26.10.20" pgsqlrep_type=remote

[database_all:children]
database
database_replica

[database_all:vars]
pgsqlrep_password=password4

[all:vars]
<<CLIPPED>>
pg_host='10.26.10.22'
<<CLIPPED>>

inventory_ha_dr/inventory_ha

[tower]
towervm1 ansible_host="10.26.10.50"

[database]
towerdb2 ansible_host="10.26.10.21"

[database_replica]
towerdb1 ansible_host="10.26.10.20" pgsqlrep_type=local
towerdb3 ansible_host="10.26.10.22" pgsqlrep_type=remote

[database_all:children]
database
database_replica

[database_all:vars]
pgsqlrep_password=password4

[all:vars]
<<CLIPPED>>
pg_host='10.26.10.21'
<<CLIPPED>>
  1. Copy tower-vars-base.yml to tower-vars.yml for customization in your environments
cp tower-vars-base.yml tower-vars.yml
  1. Modify the tower-vars.yml file for your environment. A description of the most commonly customized values are provided below. This includes definition of the inventory file for each configuration (primary/normal, HA, DR) and referencing their location. This file will be read in by all toolkit playbooks
# version of Ansible Tower to install/working with
tower_version: 3.3.0-1

# determine if the bundle is being used
tower_bundle: true

# indicated whether this will be installed without internet connectivity
tower_disconnected: true

# list of Ansible tower installer inventory files for each configuration
tower_inventory_pm: inventory_ha_dr/inventory_pm
tower_inventory_dr: inventory_ha_dr/inventory_dr
tower_inventory_ha: inventory_ha_dr/inventory_ha

# indicate whether the database is managed by the installer and toolkit or
# provided as a service.  If set to true, all replication configuration is skipped
tower_db_external: false
  1. Run the tower-setup.yml playbook. This playbook will take care of downloading the tower installation media for you installation (if it does not yet exist) and running the tower installer. The version to be downloaded and/or used in the installation is found in the tower-vars.yml file.

If you are running in a disconnected environment set the tower_disconnected variable to true and ensure the installer bundle is already downloaded. For example for 3.3.1 ensure tower-installer/ansible-tower-setup-bundle-3.3.1.el7.tar.gz is in place

ansible-playbook tower-setup.yml

If you want skip running Ansible Tower setup and only utilize this playbook to download the correct installer you can override the tower_download_only variable and run the playbook.

ansible-playbook tower-setup.yml -e 'tower_download_only=1'
  1. Run the tower-dr-standup.yml to prepare the failover cluster and configure replication.
ansible-playbook tower-dr-standup.yml

If applicable, you may want to check the status of the replication

ansible-playbook tower-check-replication.yml

At this point the secondary/DR machines are ready for failover and streaming replication enabled

HA Failover

In the event of a database outage in the primary database the following playbook can be run to failover to the HA replica

ansible-playbook tower-ha-failover.yml

Once the primary database has been repaired you must re-enable replication to synchronize data before failing back. Also ensure the database_replica group has the repaired database host if you took it out before doing the HA failover. The easiest way to enable the replication is to re-run the failover playbook.

ansible-playbook tower-ha-failover.yml

This won’t have any effect on the running cluster but will re-enable replication. If you wish to be more targeted/explicit you can also run

ansible-playbook -i INV_DIR/inventory_ha tower-setup-replication.yml
HA Failback

to failback to the original configuration

ansible-playbook tower-ha-failover.yml -e 'tower_failback=1'
DR Failover

In the event of a primary datacenter outage, the playbook can be run to failover to the secondary database (including pointing to the DR replica)

ansible-playbook tower-dr-failover.yml

Once the primary datacenter has been repaired you must re-enable replication to synchronize data before failing back. Also ensure the database_replica group has the repaired database host if you took it out before doing the DR failover. The easiest way to enable the replication is to re-run the failover playbook.

ansible-playbook tower-dr-failover.yml

This won’t have any effect on the running cluster but will re-enable replication. If you wish to be more targeted/explicit you can also run

ansible-playbook -i INV_DIR/inventory_dr tower-setup-replication.yml

to failback to the original configuration

ansible-playbook tower-dr-failover.yml -e 'tower_failback=1'

Backup and Restore

Ansible Tower Backup and Restore Documentation

Clustering

In addition to the base single node installation, Tower offers clustered configurations to allow users to horizontally scale job capacity (forks) on nodes. It is recommended to deploy tower nodes in odd numbers to prevent issues with underlying RabbitMQ clustering.

Tower clustering minimizes the potential of job execution service outages by distributing jobs across the cluster. For example, if you have an Ansible Tower installation with a three node cluster configuration and the Ansible Tower services on a node become unavailable in the cluster, jobs will continue to be executed on the remaining two nodes. It should be noted, the failed Ansible Tower node needs to remediated to return to a supported configuration containing three or more nodes. See setup considerations

Tower cluster nodes and database should be geographically co-located with low latency (<10 ms) and reliable connectivity. Deployments that span datacenters are not recommended due to transient spikes in latency and/or outages.

Database Availability

Ansible Tower utilizes PostgreSQL for application level data storage. The Tower setup process does not configure streaming replica configuration/hot standby configurations, which can be used for disaster recovery or high availability solutions. Streaming replication can be enabled and configured as a Red Hat Consulting delivered solution. The Tower database can be replicated to high availability instance in the local datacenter and/or to a disaster recovery instance in a remote datacenter. The later being utilized in a disaster recovery scenario. In the case of a failure in only the local database, the high availability instance can be promoted to a primary instance and the Tower cluster updated to utilize the instance. In the case of a full primary datacenter outage, the disaster recovery instance can be promoted to a primary instance a new Tower cluster deployed and pointed to the instance.

Disaster Recovery

As discussed above, Ansible Tower clusters can not span multiple datacenters and the default setup configuration does not support multiple clusters. This toolkit aims to provide a toolkit to bring a secondary cluster online.

Connect with Red Hat Services

Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Join the Red Hat Learning Community
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Universidade Federal de Campina Grande (UFCG), a public university in Brazil, has a rich history of providing its students with a vast knowledge of open source skills. For over 15 years, this university has been a prominent OpenStack community contributor globally with more than 150,000 lines of developed code and 30 individual contributors. The university is also contributing to the ManageIQ community as well.

The university began partnering with Red Hat Academy roughly 18 months ago with the goal of offering Red Hat Academy courses to train students and prepare them to become contributors in open source communities. The institution is hoping this will also scale the ability to develop applied open source research.

With a reputation as one of the leading technology universities in the country, UFCG wants their students to graduate  with the necessary practical experience to build careers. UFCG and Red Hat are working together to set up a dedicated lab of up to 100 students to learn about Red Hat® Enterprise Linux®, Red Hat solutions, and other in-demand technologies. The new Red Hat Academy lab and course curriculum will be available for the 2019 school year. For the 2019 school year, Red Hat donated 30 laptops for students.

So far, 10-20 UFCG students have completed the Red Hat Academy program. The resources and materials from Red Hat have helped UFCG standardize their curriculum and teach more students Linux technology.

By partnering with Red Hat Academy, UFCG has been able to provide hands-on labs, which provide students the practical experience with Red Hat technologies and simulated real-world IT scenarios to help students learn the skills necessary to tackle today’s IT projects.  To validate these skills before graduation, the Red Hat Academy offers a 50% exam discount for students on Red Hat Certification exams.The involvement in the Red Hat Academy has enhanced the university’s reputation as a technology education leader both nationally and worldwide.

To learn more about the partnership between Red Hat Academy and Universidade Federal de Campina Grande, visit: https://www.redhat.com/en/resources/federal-university-campina-grande-success-snapshot

Connect with Red Hat Services

Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Join the Red Hat Learning Community
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn

Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview