devopsy.kinsta.cloud

Tag: ansible

  • Red Hat Rises to Data Management Challenges

    Red Hat Rises to Data Management Challenges

    Red Hat is moving to reduce or eliminate many of the manual tasks DevOps teams routinely encounter via a beta release of an update to Red Hat Enterprise Linux (RHEL) that addresses multiple data management issues related to DevSecOps and DataOps.

    Steve Almy, principal product manager for RHEL, said version 7.5 of RHEL adds support for integration between the Ansible IT automation framework that Red Hat now bundles in the RHEL operating system and OpenSCAP, a security auditing tool originally developed by the National Institute of Standards and Technology (NIST). OpenSCAP provides IT administrators with a baseline of security settings to compare with the current state of their Linux deployment. They then can invoke the declarative Ansible framework to automatically resolve any of those issues raised by the OpenSCAP audit, said Almy.

    In a similar vein, Red Hat is also making it easier to securely unlock Network Bound Disk Encrypted devices at boot-time while adding time-stamping and synchronization needs with the addition of failover with bonding interfaces for Precision Time Protocol (PTP) and Network Time Protocol (NTP).

    Additionally, to reduce data management headaches, Red Hat is now embedding support for data deduplication and compression software based on technology it gained by acquiring Permabit last year. The goal is to enable IT organizations to perform those tasks on data running on the server before it is ever stored on a disk, said Alby. In many cases, that may eliminate the need to acquire, deploy and manage separate data deduplication and compression software for the storage system. That approach also serves to indirectly benefit DataOps, an emerging discipline through which many organizations are trying to modernize the management of data and the pipelines employed to feed that data into applications.

    Other additional management capabilities being added to RHEL 7.5 include an easier-to-use cockpit administrator console for managing storage, networking, containers and other services, and a “known-good” bootable snapshot to help speed recovery and rollback after patching software.

    Almy said Red Hat is focusing more on eliminating much of the friction that gets in the way of enabling IT administrators to accomplish more tasks in a specific amount of time. The goal is not to eliminate the need for IT administrators, but rather to eliminate tasks that conspire to make managing IT more time-consuming than it need be. Much of that Red Hat strategy is anchored around an Ansible automation framework that doesn’t require IT administrators to know how to program to automate the management of underlying IT environment.

    It’s not clear just how much ease of data management impacts IT decisions. All things being relatively equal, however, IT administrators in the agile programming age are trying to manage more workloads than ever. Most organizations are not adding additional IT operations staff mainly because it’s hard to find and retain them. That means make sure existing IT administrators are more efficient than ever by embracing IT automation whenever and wherever possible to streamline DevOps processes.

    — Mike Vizard

  • DevOps, Security, AI Convergence on Horizon

    DevOps, Security, AI Convergence on Horizon

    DevOps is regarded as practice that can drive performance advantages. Artificial intelligence is showing very real promise across the security market. Most public and private-sector organizations know that they must explore new and different ways of defending their networks against modern threats. These three factors make it clear that DevOps, AI and security are ripe for convergence.

    Defining AI

    Anyone reading this post doesn’t need me to explain to them what DevOps and security are; both of these categories are well-defined. However, AI is really in an emergent stage, with different types in use and many definitions floating around. Because of this, I think it is important to let readers know that in this post, AI refers to a class of technology that can:

    • Consume data, learn and get smarter on its own
    • Automatically identify and solve problems
    • Operate independently, without human supervision
    • Scale massively
    • Move at near real-time speed
    • Achieve levels of accuracy that are beyond human capabilities

    DevOps and Security are United

    DevOps and security have merged. For several years now, organizations have been leveraging automation technologies and DevOps practices to continuously deliver security and compliance policies across data centers and clouds.

    Further legitimizing the union is the fact that leading DevOps and automation players such as Puppet, Chef and Ansible have formed numerous partnerships that deliver effective security capabilities to their customers.

    There are, of course, other signs that show how successful the DevOps and security marriage has been. One of which is the emergence of the term “rugged DevOps.” It is now so widely recognized that it commands its own section on this site and is often the subject of discussion at several notable security conferences.  

    DevOps and AI are Dating

    The relationship between DevOps and AI is in the early stages, with the courtship between the two well underway. Examples of its progress are found in numerous blogs and articles, several of which include:

    DevOps and AI have certainly not yet intertwined as deeply as DevOps and security have. These examples (and others out there) do show they the two will continue to integrate beyond what we are currently witnessing.

    DevOps, Security and AI

    DevOps and security are wed. DevOps and AI are moving closer toward each other. It’s only a matter of time until all three get together.

    Because several DevOps leaders are already in the business of security, it’s logical to assume that a partnership between one of them and an AI-driven security provider will be what ultimately leads to a marketable solution.

    DevOps provider candidates with the potential to move on a partnership that can combine DevOps, security and AI have a raft of new and established security providers available to work with. Several of the startups in this class are recognized in the CB Insights AI 100 2017 infographic. Companies such as Cloudera (NYSE: CLDR), which is using AI and machine learning to solve security problems, are among the more established providers that may make for a perfect partner. 

    How quickly will the market see such a partnership? That remains to be seen. However, with DevOps now fully accepted as a methodology that can positively impact bottom lines, AI coming into its own, and the need for new and different ways of defending organizations against attacks at a critical stage, it seems almost certain that the convergence will be upon us sooner rather than later.

    — Joe Franscella

  • VMware Cloud on AWS Will Bring DevOps Issues to a Head

    VMware Cloud on AWS Will Bring DevOps Issues to a Head

    Now that instances of VMware are starting to become available on Amazon Web Services (AWS), a DevOps ecosystem is starting to emerge around the management of applications workloads moving into and out of AWS.

    Among the more than 4,500 applications that VMware claims already support VMware Cloud on AWS are those from Blue Medora, CA Technologies, Chef, Cloudbees, Dynatrace, Jfrog, Puppet, SaltStack and the Ansible arm of Red Hat.

    VMware CEO Pat Gelsinger told attendees at the recent VMworld 2017 conference that VMware and AWS are just now scratching the surface of what they plan to accomplish together. AWS CEO Andy Jassy added that, unlike other alliances, which consisted mainly of marketing, engineers at both companies are working closely together to deliver VMware globally across all AWS availability zones. At present, VMware Cloud on AWS is available in the AWS availability zone hosted in Portland, Oregon. The service soon will be extended to the east coast of the United States, followed by rest of the world over the course of 2018.

    The availability of VMware Cloud on AWS should force several DevOps issues within enterprise IT organizations that have deployed the VMware stack of software mainly on-premises. Many of those organizations have also been employing public clouds such as AWS. But because those environments are based on different hypervisors, it was never easy to migrate workloads between the two platforms. There are plenty of options for running VMware software in the cloud, but because AWS is the largest provider of public cloud services, there are many customers who want to seamlessly move workloads between their on-premises IT environments and AWS via a common stack of VMware software.

    In many organizations the desire to shift applications workloads into AWS will bring many DevOps issues to a head, as VMware and AWS use has occurred in independently of each other. There could be many workloads running on each platform, but for all intents and purposes, IT organizations have managed both platforms in isolation. Now that VMware is becoming available on AWS, all the challenges associated with moving workloads between a public and private cloud come to the fore.

    Most of those DevOps issues will be focused first on moving some classes of workloads running on VMware into AWS. Application workloads that don’t need to run constantly will be among the primary candidates followed by a slew of data protection applications that will enable IT organizations to back up and archive massive amounts of data inexpensively. Next up will be applications that need to be distributed globally to increase availability.

    At the same time, a lot of VMware shops will be moving application development into the cloud. But just because an application is developed in the cloud doesn’t mean it will stay there. Many IT organizations have already discovered that when it comes to long-running applications, the total cost of deploying them on-premises is less than deploying them on a public cloud. The DevOps tasks ahead, of course, will start with figuring out which VMware-based applications make the best candidates from a financial and availability perspective to be deployed on AWS.

    — Mike Vizard

  • SecOps: The Next Stride for DevOps

    SecOps: The Next Stride for DevOps

    Global IT spending is now touching a figure of $4 trillion. In today’s technology-intensive environment, data is the biggest commodity, more valuable and powerful than ever. And like Peter Parker’s uncle Ben noted, “With great power comes great responsibility.”

    Security has always been a big concern for valuable things and IT is no exception. IT as a whole is trying to push security left in the development cycle—trying to involve it in every step of the development cycle. And just when development and operations teams are getting used to the “esprit de corps” we call DevOps, I think it’s time we add the third musketeer: security.

    What is SecOps?

    SecOps is a collaboration between security and operations teams, just like development and operations teams collaborate on DevOps front. SecOps is a set of practices organizations need to follow, processes they need to execute and tools they need to use to ensure the security of their application environment. SecOps is making sure organizations do not sacrifice security to attain set performance and uptime indexes.

    In a typical development cycle—requirements gathering, design, development, testing, implementation or deployment and maintenance—security normally is introduced in the later stages, somewhere between testing and deployment or even later. But SecOps is all about making sure to introduce aspects around security much earlier or at each stage of the software development life cycle (SDLC).

    I know what you are thinking: This is going to complicate things and increase the time to delivery. This is where operations and development teams need to join forces to uncomplicate the things and make it time efficient practice. Next thing you must be thinking of is, Why so much hassle? Think of it the other way. Wouldn’t it save more time when you address the security concerns at much earlier stages than at the time of delivery or implementation? All it takes is an amalgamation of the security group, development team and operations team; a little bit of planning; and a whole lot of execution.

    SecOps + Containers

    Containerization is slowly but steadily moving from an alternative to full virtualization to a serious platform for running your applications. Containers have some obvious advantages including scalability and flexibility, and this solves most of the problems related to resources in case of application development. Reduced size; reduced time to provision application environment and testing; platforms including Docker, Solaris Zones, BSD Jails; and orchestration platforms including Kubernetes, CoreOS Fleet, Amazon ECS and OpenShift make containers a more preferred option for application development environments.

    This increased traction toward containerization points to the increased need to concentrate on security aspects. Here are some best SecOps practices for container environment you and your organizational teams can follow:

    • Authentic sources and images: Always check for authenticity of container images. There are various tools such as Docker’s security scan. With Docker Cloud and Docker Hub you can scan images to check for potential security vulnerabilities. Most images are built from some base image and not built from scratch, so there is always a threat with the used images.
    • Vulnerability management tool: There are tools available in the market to analyze container image formats and libraries for threats before you actually start using them.
    • Follow benchmarks and hardening guidelines: Always make sure you do the checks and follow hardening guidelines for containers, images, hosts and platforms before you start with production. There are few standards and benchmark checks for containers such as CIS’s Docker security benchmark, PCI compliance checklist, etc.
    • Periodic auditing: Regular auditing of your application environment can help you save yourself from the future troubles. Moreover, automation of auditing process can help in detection of unused images and containers.
    • Use of management frameworks: Use frameworks that can automate behavior profiling and control all the users, authorize the access to the containers, images and hosts.
    • Security built in to container engine systems and third-party security solutions: Third-party vendors have a number of applications for container security in addition to security systems of container management platforms.

    Dev + Sec + Ops

    With the continuously increasing business demands for new applications and software, and new practices and development trends such as DevOps, Agile, cloud, automation, CI/CD and others, traditional security needs to upgraded in the new paradigm. Thankfully, some of these practices facilitate the security. Consider CI/CD as an example: Continuous integration requires continuous integration tools, or what we call build servers. Some popular examples are Jenkins, TeamCity, GitLab CI, Travis CI, Bamboo, Go CD, CircleCI and Codeship. The best SecOps practice is to check and fix vulnerabilities at early stages as a part of CI/CD workflow. Integration between authentication, scanning, management tools and CI/CD pipeline tools could be the best possible solution to your security-related problems. Some easy-to-implement solutions can include automated security testing, static code analysis, authentication checks and login tracking.

    SecOps enable organizations in lifecycle management, analysis of security threats, incident management, optimizing and measuring the effectiveness of security controls, reduced breach response time, reduced security risks and increased business security. The basic principle on which SecOps works is Avoid, Analyze, Respond, Review, Repeat. By analyzing the security events and data, you can build incident response plans to avoid future unwanted events.

    Frameworks and Tools

    Now that you have a clear understanding of why you need your security, development and operations teams to work together, let’s see what tools and frameworks you can use.

    • Docker-native tools: If you are using Docker as a platform then you can use few security tools provided by Docker itself for the security of production environment: Docker Bench and Docker Notary. Docker Bench is a script that checks common best practices around deploying Docker containers in production. Docker Notary enables you to check whether content is from a trusted publisher.
    • Chef: Chef provides different tools including Inspec to automate security testing.
    • Puppet: Puppet provides security compliance and policy defining frameworks.
    • Ansible: Ansible provides system tracking, setting up firewall rules, user lockdown and compliance automation solutions.
    • CoreOS Clair: CoreOS Clair is an open-source project for vulnerability analysis in applications and Docker containers.
    • SaltStack: SaltStack can help in orchestration and automation of security practices solutions for containers.

    This is just a look at some of the most popular ones. If you want, there are a number of others that can look after the security of your application environment.

    The main motive behind implying SecOps practices in any organization is involving security team at all possible stages to remove any ambiguity in any stage of development rather than security team providing analysis reports to the operations team and then sitting back and enjoying the show. When these teams perform in a synergistic manner, the business focus can be shifted to other important things.

    About the Author / Chaitanya Jawale

    Chaitanya Jawale is founder and CEO of Opcito Technologies, a leader in microservice-based product engineering and automation. Chaitanya comes with strong background in product engineering, data center automation, DevOps and multi-cloud orchestration and management.

  • When DevOps Disrupts DevOps

    When DevOps Disrupts DevOps

    As longtime readers of my blogs will know, one of my hobbies—when not writing about or playing with technology—is modeling. There is a similarity between quality tech work and quality modeling, but the brain power involved in modeling is much less, leaving me time to think about tech issues or listen to audiobooks (when I’m not listening to music, anyway).

    In modeling, as in tech, there is a process. The process varies based upon what you’re working on, but is largely the same, with some steps slightly different or skipped altogether and others taking longer. At the moment, I’m building the first day of Gettysburg from the American Civil War, but I simply enjoy modeling—and wargaming with the models, but that’s a separate story for a hobby-focused blog.

    The thing is, that process is nailed down, and to the extent it can be, is automated. One step leads reasonably to the next, and while one step is completing on a given model (glue or paint drying, etc.), there is an opportunity to advance a separate project.

    Sounds a lot like DevOps, doesn’t it?

    The thing is, every once in a while, you will get something that is so different, it totally interferes with the carefully planned flow. My current primary project is a little over 300 figures. While one unit is getting the final two coats of finish (that are basically the same or every model), the next unit is getting primed. Assembly of all the figures came first, so there is only the priming step before painting can commence.

    Picture, but you missed it.
    Piper Millin and Lord Lovat cross Pegasus Bridge.

    But here is a work-in-progress picture of Pegasus Bridge. This came as a complete set, and took a large chunk of time to get together, find the correct water for, get placed on foundation boards, etc. This is outside the normal process of assemble/paint/base figures and vehicles. The set is beautiful, and even this picture, which was taken well before completion and only to study color and weathering effects versus reality, shows how truly nice the model was. But it totally disrupted the process flow.

    DevOps and Multisystem Installations

    That’s what complex system installations such as Hadoop or OpenStack do. You’re installing across multiple systems, configuring them for load-sharing and communication, and doing it by hand is a long process that interrupts the normal DevOps flow. Crafting scripts to install them is possible but highly complex and frustrating, simply because of the complexity and interrelationship of the nodes in the system.

    Having installed both by hand, and installed both with tools designed to make it easier, I will happily tell you that yes, you will understand more if you do it by hand, and no, that immediate understanding is not necessarily worth the cost of weeks or months figuring it out and getting it installed.

    You see, to operate these systems, you will need much of the knowledge you would gain hand-installing, so you’re going to learn it either way. Your choice is a simple one: Get a working system and learn by tweaking settings or swapping nodes in and out, or have no working system and learn by the frustrating process of trying to figure out what you’re supposed to do next, and why that step is failing for your specific hardware.

    DevOps and Multisystem Maintenance

    The only real problem is that it is painful to maintain these systems. It’s not as simple as

    yum update [[packagename]]

    because that would only upgrade one package on one system. But these tools span multiple systems, and even just dependencies generates a massive list for each system in the cluster. Seeing the need, most of the traditional application provisioning tools (Puppet, Ansible, et al) have built or cobbled together solutions that will get the job done. But custom solutions exist for these products, too. The problem is that, like Pegasus Bridge, as beautiful as they are they disrupt the DevOps flow. No system goes without exceptions, and I’ll go out on a limb and say that custom solutions to install and maintain solutions such as Hadoop and OpenStack are worth having yet another tool in the DevOps tool chain. The trend is multipurpose tools to be used on many projects, but the importance of a cloud or big data cluster in your IT operations makes them worth the extra tool. As long as the extra tool reduces the amount of work and the chances for human error (which, in my opinion they do—it is kind of their selling point).

    That Leaves Time

    These tools (a good example, though in general I won’t be talking about the competing vendors here, is the Mitaka-based release of Mirantis) allow not just installation but also ongoing management of the OpenStack cloud or big data cluster. That means there is less nitty-gritty for DevOps (or operations for that matter) teams to worry about, freeing time for working on what actually gets built on top of these powerful platforms. Cloud and big data both are just enablers for more functionality when looked at in the right light, which means more work (and often more meaningful work) for DevOps teams.

    When you consider either of these technologies, check out what’s available for installation and maintenance, even if it is outside your normal DevOps tool chain. Like Pegasus Bridge, the change is likely to disrupt you for a bit, but once you have a tool and process in place, it will just be something that happened—and was going to happen with or without the tools. They just make it less painful.

    — Don Macvittie

  • So Long to Configuration Management Systems?

    So Long to Configuration Management Systems?

    When I was an operations architect at Ning way back in 2009, we were struggling to manage our deployments and configurations of more than 50 different application servers, or what the cool kids today call microservices. Applications were deployed across three distinct environments: development, staging and production. None of these environments were exactly the same as another, and differences in these dependencies, together with human errors, frequently broke our deployments.

    Ning was nowhere near the first company to encounter such problems. In the mid-1990s, as the public internet emerged, much of what was understood at the time about IT operations was challenged by the need to scale internet-facing systems. For many years preceding the internet boom, the maximum number of users was strictly limited to the number of employees in a company. That all changed with the World Wide Web, where the need to serve thousands and millions of simultaneous users easily exceeded the computing capacity of even the largest and most expensive computers.

    As three-tier application architectures were broken down into services and distributed across dozens or hundreds of individual servers, this proliferation of servers proved to be far too much for operations teams to handle. The worst problems lived within application deployment processes, where environments and requirements were ever-changing in successive releases of software. The lifetime of a server was a long one. Once deployed, servers were subjected to repeated changes by operations and developers in what would come to be called “configuration drift.”  The combined effects of changes, human errors and unknown states would create disastrous outages that damaged brands and destroyed online revenue. It would take sites days and even weeks to recover from these outages. Some would never recover.

    It was in the midst of this chaos that modern configuration management systems were born. CFEngine was the first to emerge in academia, where the need to manage multiple UNIX systems was felt early on. Later, Puppet, Chef, SaltStack and Ansible emerged directly from web-scale systems. Configuration management systems fulfilled several important needs. First, they abstracted the differences between operating systems, providing a high-level language for the system administrator to describe the desired state. Second, they automatically synchronized the desired state across large numbers of servers, reducing costly human errors. Finally, they provided idempotency to ensure that destructive operations were not applied unnecessarily.

    There is never a free lunch. The benefits of better abstraction were offset to a degree by the need to build and maintain evermore complicated recipes. Recipes frequently broke from time to time as package management features were updated, renamed or otherwise changed from the time the recipe was first written. Even when recipes worked, they were frequently broken by differences in environments or runtime errors. The configuration management systems themselves began to suffer from scale challenges, and evolved message bus architectures to improve their speed and responsiveness. By overcoming many of these obstacles, configuration management systems have now become a first-line tool for managing web-scale systems.

    But back at Ning, modern tools such as Puppet and Chef were still in their infancy and simply could not cope with the scale of our 60,000+ node virtualized environment. Ning had a lot of brilliant software engineers floating around, and they set about creating their own deployment automation system called Galaxy, and later a meta-orchestrator called Cosmos. Galaxy and Cosmos were great tools, but they required constant care and feeding and suffered from severe scale problems. There was just a lot of complexity in dealing with these automation systems while also trying to scale a top-tier social network for a hot startup company.

    As we began to analyze and post-mortem our deployment failures, it became clear that a majority of the problems stemmed from host and environment configuration errors. We needed a simpler way to deploy our software. Virtual machine images were a promising way to ensure consistency between environments with the tried and true “gold master image” approach. The problem with this approach was that building full system virtual machines was difficult in automation terms. Once deployed, virtual machines are also subject to configuration drift. Furthermore, while we were eager to adopt virtualization to get better resource isolation, we were wary of the overhead that hypervisors would create. Our benchmarks showed that if we adopted virtual machines, we would need to increase our physical server capacity to accommodate the overhead.

    At the time, Linux containers were already available in the kernel, but the distributions had almost no support for managing them. At the insistence of our VP of Operations, I cooked up an alternative solution based on jails, writing a small hack of a program called Warden to build and manage them. (Note: Totally unrelated to the Warden in Cloud Foundry). Jails gave us bare metal performance, resource isolation and a way to consistently deploy the entire environment for each application server.  With Warden, we could build jail images on the fly automatically and deploy them consistently with our existing tools, galaxy and cosmos. Hey, it was a Band-Aid for a difficult situation, but my experience with building Warden flipped a switch in my brain. I had seen the way lightweight virtualization could eliminate complexity, and I knew right then this was the way of the future.

    Today, with the success of Docker we are finally experiencing sweeping changes in the processes and tools we use to build, deploy, and manage distributed applications. At the same time, we are about to enter a brief period of containers disillusionment as early stage solutions get washed out. When that is over, what comes afterward is something of a golden era for distributed applications. I call it the container application platform, and its somewhere between what we think of as platorm as a service (PaaS) and Serverless today. In that not-too-distant future, containers will be the default output of the software build process, and where that container gets deployed will hardly be an afterthought. This unicorn magic will come from the ability to introspect containers to determine their environment dependencies, and a fully integrated tool chain that deals with deployment, scaling and dependency resolution automatically. I will give you just one guess which company is in the best position to own that future. “One ring to rule them all.”

    What happens to our beautiful configuration management systems? There has been much debate about this among smart people over the last few years. Most of these arguments boiled down to some kind of coexistence model. Indeed, configuration management systems are useful for dealing with a wide range of operational problems outside of the container platform. While it’s no surprise that Chef, Puppet, Salt and Ansible all moved quickly to include Docker support, I think we will see these tools begin to focus more on what Rob Hirschfeld calls achieving “ready state”. That is to say, everything that still needs to be done before you can lay down your container platform also still needs to be automated. Right now, that is still a great deal of work, and it’s a pretty safe place to draw the line on using the right tool for the right job.

    About the Author / James Thomason

    james-thomason_dsc0492James Thomason is chief technology officer at HyperGrid from Dell, where as CTO he led the vision, technology strategy and product road map for Dell Cloud Marketplace. He joined Dell through the acquisition of Gale Technologies in 2012, where as CTO he headed the product road map, architecture and engineering of the company’s flagship cloud and converged infrastructure automation software, GaleForce. Prior to joining Gale Technologies, Thomason was the CTO and Founder of Virtiv, a San Francisco cloud automation startup focused on Linux virtualization, acquired by Gale Technologies in 2011. For over 17 years, as a specialist in distributed systems and large-scale infrastructures, Thomason has been an entrepreneur and innovator at a number of notable Silicon Valley startups, including Exodus Communications, Digital Island, Netli, NetVMG, Netscaler, 3Leaf Systems and Ning. Connect with him on LinkedIn / Twitter.

  • Orchestration: How To Get Everyone in Tune

    Orchestration: How To Get Everyone in Tune

    Automation is key to success in the cloud. When your entire infrastructure is accessible via an API, it doesn’t make sense to configure and install your applications by hand. This is where orchestration tools come into play.

    Simply put: You will not have long-term success in the cloud unless an orchestration tool is a core part of your strategy.

    Orchestration Tool Uses

    Each orchestration tool works in roughly the same manner, taking a set of instructions (Chef uses recipes, Puppet uses manifests and Ansible uses plays) and applying them to one or more systems. The syntax of the instructions and how they are applied changes with each tool, but the principles are consistent.

    This leads to the most common use case: configuring a new server.

    Instead of manually installing all of the required libraries, applications, config files and other tools, you simply run the matching set of instructions. Need a new web server? One command and you’re set. Need a database server? Another command has it up and running quickly.

    That’s the basic idea, but with each of these tools you easily can build out a more complex configuration by nesting sets of instructions. Taking the two examples above, you could have a baseline server configuration with all of the common tools and configurations, then customize each server with a smaller set of configurations specific to web servers and database servers.

    Does a new utility need to be on all of your systems? Do you have a new version of your app? Do you need to push out a new configuration file for your data stores? Send one set of instructions through your orchestration tool and you’re done.

    It doesn’t take long to see the value of these tools and to mandate their use for all of your cloud deployments.

    Not So Fast

    Like most challenges in the DevOps space, orchestration isn’t that simple. You can’t just wave your magic wand and get all of your teams using a centralized orchestration tool. This is not a new challenge, we’ve been trying to get this right since the early ’90s (remember Novell ZenWorks or the first version of Microsoft Systems Manager?) and are just now starting to see wide(r)spread success.

    Culture is the No. 1 blocker when it comes to this category of tool.

    You’ll hear some common objections from teams:

    • The choice of technology (is Chef versus Puppet versus Ansible versus the Emacs versus Vi?)
    • It wasn’t built here.
    • The manual process works just fine.

    These objections rarely hold up to scrutiny, but that doesn’t matter. Any objection raised needs to be addressed in some manner until you’ve got enough people on the target team to sway the rest over to the direction you’re trying to head.

    When you’re facing a cultural challenge, you have to address the people side of the equation in your strategy!

    3 Steps to Take

    No solution is going to work in all cases, as every organization is unique. You know the culture of your organization best, so go with your gut. With that in mind, here are the three approaches that tend to work best for most organizations.

    1. Empathy

    No one likes to be told what to do from up on high. While mandating that a team switch over to this shiny new orchestration tool might get the work done initially, it also will build resentment. That’s the opposite of what you want. You want buy-in.

    Odds are, each team in your organization already has a to-do list a mile long. Regardless of the benefits, your orchestration project probably isn’t very high on the list. Accepting that your priority isn’t their priority is a key step toward understanding and empathy.

    2. Pitch In

    One way to help move up the priority list is to offer to help out and pitch in.

    Learning a new tool and new way of conducting ops doesn’t just happen overnight. Have a strong, step-by-step plan to help bring other teams up to speed. A core part of that plan has to be one of your team working with the new team for as long as it takes to get them comfortable with the new tool.

    Take a patient, hands-on approach. Let other teams learn by doing … and by making mistakes. Your role is to guide them along the path of adopting the new tool. Time and time again, this type of approach has proven to be far more successful than other options.

    3. Duct Tape

    As your efforts progress, you may reach the point where the other teams are comfortable with the tooling, understand the workflow and are ready to adopt the new tool.

    The problem is now either:

    1. Developing new sets of instructions or
    2. Converting old scripts or hacks to the new tool.

    To tackle the first challenge, make sure you’ve set up an easy way for teams to share sets of instructions. A centralized set of git repos work great for this. This will reduce the overall workload and encourage collaboration. It’s better to borrow than to rewrite.

    You’ll also want to make sure there is a regular communication highlighting successes with the new tooling. This will help remind teams of the value of the new way of working.

    To tackle conversion (problem No. 2), plug your nose and use this messy hack. All three major orchestration tools allow you to execute another script or program. If you already have working sets of instructions, keep using them. Just wrap them in the new tool to gain the workflow benefits.

    Eventually you will replace them with native instruction sets, but if it’s working “as is,” that’s one less set that you need to build.

    Smoother Operations

    A lot of operational issues happen because of a manual error. Asking someone to make the same configuration change on six systems is bound to lead to a mistake. By moving to the cloud, you’ve already accepted the ability to program your infrastructure. Manually configuring the assets in that infrastructure doesn’t make any sense.

    Orchestration tools allow you to reduce the number of mistake made, ensure consistent results and amplify the productivity of your teams.

    What’s not to love?

    What have your experiences moving a number of teams to a common tool been like? What tips and tricks did you learn along the way? Share in the comments below or on Twitter, where I’m @marknca.

  • Red Hat Launches Ansible-Native Container Workflow Project

    RALEIGH, N.C.–(Business Wire)–Red Hat, Inc. (NYSE: RHT), the world’s leading provider of open source solutions, today announced the launch of Ansible Container under the Ansible project, which provides the leading simple, powerful, and agentless open source IT automation framework. Available now as a technology preview, Ansible Container allows for the complete creation of Docker-formatted Linux containers within Ansible Playbooks, eliminating the need to use external tools like Dockerfile or docker-compose.While standardization is emerging for container formats in the form of the Open Container Initiative, the tooling space is still fragmented, with developers often forced to work outside of the enterprise workstream to create and deploy containerized applications. Ansible Container changes this dynamic, by bringing Linux container development into the existing workstream through the easy-to-consume Ansible Playbook, adding cloud-native application development side-by-side with traditional application building.

    Alongside Ansible Container, the Ansible project has also launched new Kubernetes modules which allow for the production of Kubernetes templates directly from an Ansible playbook. Combining the two new offerings, IT teams can now build Linux containers directly from a playbook and deploy to a Kubernetes-based container application platform, like Red Hat OpenShift, in a more streamlined and efficient manner.

    Ansible enables developers and IT operators to more easily and quickly deploy IT applications and environments, empowering them to remove barriers between IT teams by automating routine activities such as network configuration, cloud deployments, and creation of development environments. Ansible’s modular code base, combined with ease of contribution, and a community of contributors in GitHub, enables the powerful IT automation platform to manage today’s infrastructure, but also adapt to new IT needs and DevOps workflows.

    With the capabilities of Ansible Container, users will be able to automate their existing infrastructure and networks with Ansible playbooks, while using additional playbooks to containerize their applications and deploy them on a container application platform. This allows for continuity of operations by preserving existing IT investments and critical applications/systems without sacrificing innovation in the form of cloud-native applications and container orchestration at scale.

    The automated container creation and deployment offered by Ansible factor into Red Hat’s existing container infrastructure stack, which now includes:

    • A stable, container-centric operating system in Red Hat Enterprise Linux Atomic Host.
    • An enterprise-grade, Kubernetes- and Docker-native container application platform through Red Hat OpenShift and the recently announced next-generationOpenShift Online public cloud service.
    • Infrastructure management, automation and monitoring across hybrid environments with Red Hat CloudForms, Red Hat Insights, Red Hat Satelliteand Ansible Tower by Red Hat.
    • Massively-scalable private and hybrid cloud architecture for large-scale container deployments through Red Hat OpenStack Platform and Red Hat Cloud Suite, which also includes Red Hat OpenShift.

    Red Hat’s container stack provides a fully-open, enterprise-grade experience, from developers building cloud native applications to operations teams managing and monitoring a diverse set of hybrid applications and environments. Built entirely from upstream, community-driven projects, Red Hat’s container portfolio provides the innovation to drive the next-generation of enterprise IT while also allowing for the retention of mission-critical modern and legacy systems.

    For more details or to try it in its current form, visit the Ansible Container project.

    Supporting Quote

    Greg DeKoenigsberg, director, Ansible community
    “Many users in our community have already grown accustomed to using Ansible to deploy and manage their containers, and the Ansible Container project is an encapsulation of many of the community’s best ideas, brought together into a single tool. The user traction we’ve received in a fairly short period of time indicates to us that we’re targeting a critical need in the container tooling space.”

    Additional Resources

    Connect with Red Hat

    About Red Hat, Inc.

    Red Hat is the world’s leading provider of open source software solutions, using a community-powered approach to provide reliable and high-performing cloud, Linux, middleware, storage and virtualization technologies. Red Hat also offers award-winning support, training, and consulting services. As a connective hub in a global network of enterprises, partners, and open source communities, Red Hat helps create relevant, innovative technologies that liberate resources for growth and prepare customers for the future of IT. Learn more at http://www.redhat.com.

    Forward-Looking Statements

    Certain statements contained in this press release may constitute “forward-looking statements” within the meaning of the Private Securities Litigation Reform Act of 1995. Forward-looking statements provide current expectations of future events based on certain assumptions and include any statement that does not directly relate to any historical or current fact. Actual results may differ materially from those indicated by such forward-looking statements as a result of various important factors, including: risks related to the ability of the Company to compete effectively; the ability to deliver and stimulate demand for new products and technological innovations on a timely basis; delays or reductions in information technology spending; the integration of acquisitions and the ability to market successfully acquired technologies and products; the effects of industry consolidation; uncertainty and adverse results in litigation and related settlements; the inability to adequately protect Company intellectual property and the potential for infringement or breach of license claims of or relating to third party intellectual property; risks related to data and information security vulnerabilities; ineffective management of, and control over, the Company’s growth and international operations; fluctuations in exchange rates; and changes in and a dependence on key personnel, as well as other factors contained in our most recent Annual Report on Form 10-K (copies of which may be accessed through the Securities and Exchange Commission’s website at http://www.sec.gov), including those found therein under the captions “Risk Factors” and “Management’s Discussion and Analysis of Financial Condition and Results of Operations”. In addition to these factors, actual future performance, outcomes, and results may differ materially because of more general factors including (without limitation) general industry and market conditions and growth rates, economic and political conditions, governmental and public policy changes and the impact of natural disasters such as earthquakes and floods. The forward-looking statements included in this press release represent the Company’s views as of the date of this press release and these views could change. However, while the Company may elect to update these forward-looking statements at some point in the future, the Company specifically disclaims any obligation to do so. These forward-looking statements should not be relied upon as representing the Company’s views as of any date subsequent to the date of this press release.

    Red Hat, the Shadowman logo and Ansible are trademarks or registered trademarks of Red Hat, Inc.or its subsidiaries in the U.S. and other countries. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

    Red Hat, Inc.
    Anna Eusebio, +1-919-754-4519
    aeusebio@redhat.com

  • Continuous Delivery: The Atlassian Way

    Continuous Delivery: The Atlassian Way

    Sonatype’s Mark Miller (@TSWAlliance) caught up with Ian Buchanan (@devpartisan) for our 2016 DevOps Leadership Series. Ian discussed his experiences at Atlassian, including continuous delivery, ChatOps, and use of tools such as Bamboo, Nexus, Puppet and Datadog.

    https://www.youtube.com/watch?v=MgRaYKHGqeQ

    Buchanan: I’m Ian Buchanan. I’m a Developer Partisan at Atlassian, which is developer advocacy for our developer tools.

    Miller: Ian, most people know Atlassian from solutions like JIRA and Bitbucket.

    Buchanan: Yeah, I focus mostly on Bitbucket and Bamboo. Bamboo’s our continuous integration and deployment tool.

    Miller: Good. One of the subjects we talked a little about at dinner last night is how Atlassian is using Nexus. Can you give us some background on that?

    Buchanan: Yeah, that’s right. Well, we’re a big Java shop. We have been for a very long time and have a lot of Maven dependencies for external reasons; we also store a lot of our own internally developed libraries in our Nexus repository.

    _________________

     We’re a big Java shop. We have been for a very long time … we store a lot of our own internally developed libraries in our Nexus repository.

    _________________

     Miller: As far as a binary repository, are you using it for anything other than components?

    Buchanan: Not that I’m aware of. I know that we’ve recently started to get into Docker quite a bit and Nexus is a good fit for that as well. I don’t know the extent which we’re using Nexus for that purpose yet, as Docker’s still quite new for us.

    Miller: What does your continuous integration pipeline look like?

    Buchanan: It certainly varies by product in the details. Of course, we have our own continuous integration product, Bamboo. Bamboo is the most pervasive tool we have.

    For the Java stuff it’s pretty simple pipeline where libraries get built and published into Nexus so that they can be used downstream. We also have some interesting, newer cloud products that are built with Python. A lot of the deployments, whether they are Java or Python stuff, are handled by Bamboo’s deployment projects. They pull artifacts from Nexus and put them into production.

     _________________

    A lot of the deployments, whether they are Java or Python stuff, are handled by Bamboo’s deployment projects. They pull artifacts from Nexus and put them into production.

     _________________

    Miller: Are you guys using continuous delivery in house for your workflow?

    Buchanan: We’re in an interesting position that I think I see a lot of companies in. We have some behind-the-firewall products (our server products) and then we also have cloud products. In the cloud side, continuous delivery is used when we want to go very fast. But we also have to balance that with the approach we take for our server products so that they don’t fork terribly. We have continuous delivery up until there’s a product delivered. At that point, there is another kind of pick up—where the cloud products engage with other things like Puppet and Ansible to configure the environments with products that other people can pick up and run on premises.

    Miller: I was talking to your team in San Francisco. How are you guys using ChatOps with HipChat?

    Buchanan: I’ve been talking about ChatOps for quite some time. We do a lot of very interesting things with ChatOps. They play a very important part of our continuous delivery pipeline in that we publish build results in there. People can see when pull requests are ready and check those out. We get to see what’s happening from production as well. We have integration with Datadog; it tells us some of the monitoring things that are going on. It’s not just information coming into the chat room. There are also commands that folks can issue to make the continuous delivery pipeline move along. There are certain stages where you can type a command to our ChatOps and they will perform the necessary actions. Much of the deployment and change management happens in a ChatOps context.

    _________________

     There are certain stages where you can type a command to our ChatOps and they will perform the necessary actions. Much of the deployment and change management happens in a ChatOps context.

     _________________

     Miller: Anything coming up in the future you guys are working on that’d be fun?

    Buchanan: Well, a lot of the innovation really happens at our quarterly “Ship It” events. That’s where our developers spend 24 hours doing whatever kind of innovation interests them. A lot of time is spent scratching an itch they have. Some of the things that I saw there were about having more information coming back upstream, not just into the chat rooms, but into JIRA where more of the longer-term tracking is going on. They’re experimenting a lot with putting more information into JIRA.

    Miller: Nice. Final question, if you were going to be a superhero, would it be Dev, Sec or Ops?

    Buchanan: I’ve played Dev roles and Ops roles and I almost feel like I know those much more. But from a lot of the sessions at DevNexus, I have to feel like Sec is the superhero. They’re the superheroes because they solve some unsolvable problems in a lot of ways. But I don’t feel ready to play that role at the moment, myself.

    Miller: It’s interesting. I agree with you that they are unsung heroes. Most of the time they just get hammered for what they’re doing.

    Buchanan: That’s true. Yesterday I was in a session about securing REST endpoints. The speaker went through problems with BASIC off , DIGEST off and J2EE—all of these things which we use in our products. At the end we’re left with, “What is the answer?”

    Well, the answer is that for each of these, there are different problems. So we have to identify the right context. We have to understand where some things are broken, know that those things aren’t perfect, and design for that imperfection. That’s a mindset that we have to carry through dev, ops and sec. I hope more security folks step up and start telling those stories.

  • Red Hat Brings DevOps to the Network with New Ansible Capabilities

    Red Hat extends Ansible’s agentless automation framework to network infrastructure devices; At launch, Ansible supports devices from Arista, Cisco, Juniper, and more

    RALEIGH, N.C.–(BUSINESS WIRE)–Red Hat, Inc. (NYSE: RHT), the world’s leading provider of open source solutions, today announced that it is bringing DevOps to networking by extending Ansible – its powerful IT automation and DevOps platform – to include native agentless support for automating heterogeneous network infrastructure devices using the same simple human and machine readable automation language that Ansible provides to IT teams. With expanded Ansible networking capabilities, Red Hat is aiming to help customers orchestrate entire application infrastructures, including network devices, with one automation tool.

    The 2015 “SDx Cloud Management Report: OpenStack and More,” highlighted the results of a recent survey on cloud architectures and platforms, stating, “When asked what they felt was the most immature component in cloud management, the overwhelming response was the network at 76%.” By including network devices as part of the overall architecture of Ansible, Red Hat customers can benefit from increased IT agility through operational efficiency, bridging the traditional divide between IT operations and networking teams, and advancing agility and modernization efforts.

    Using Ansible’s simple, powerful, and agentless approach, organizations will have the ability to unify operational methodologies across their IT infrastructure in a new way – by orchestrating compute, applications, virtualization, and now, networking. This approach offers many customer benefits, including:

    • For network teams looking to apply more agile DevOps methodologies to network infrastructures, Ansible can enhance their ability to build and operate heterogeneous network devices, freeing them up to focus on evolving the network to meet the changing business needs instead of manually pushing network configuration.
    • For systems and applications teams that wish to include network devices in a holistic approach to application workload management, Ansible’s native network device support enables them to extend their DevOps tools and practices to heterogeneous network devices.
    • For executives and senior management concerned about their organization’s ability to automate and orchestrate solutions in an increasingly complex IT environment, Ansible provides a framework that integrates diverse network devices without introducing vertically integrated, vendor specific applications and operational methodologies.

    At launch, Red Hat’s Ansible networking framework provides support for:

    • Arista Networks – Arista EOS;
    • Cisco Systems – Cisco Application Centric Infrastructure (ACI); Cisco IOS-XE®; Cisco IOS-XR®; and Cisco NX-OS;
    • Cumulus Networks – Cumulus Linux;
    • OpenSwitch.net – OpenSwitch; and
    • Juniper Networks – Junos OS.

    Availability

    Support for automating network infrastructure devices in Ansible is available immediately.

    Supporting Quotes

    Todd Barr, general manager, Ansible, Red Hat

    “Today’s networks are complicated, and largely comprised of multi-vendor solutions, making them rather inflexible and slow to react to business changes. Bringing a DevOps mindset and approach to the network gives customers the ability to make network operations a repeatable, more predictable, and automated process. By bringing the power of Ansible, the popular open source IT automation solution, to the network, we’re giving customers the ability to solve their complicated networking automation and workflow problems in a new way.”

    Jay Lyman, research manager, Cloud Management and Containers, 451Research

    “The cloud and automation offer a significant opportunity to evolve and advance the network, bringing together once disparate technologies and teams. Through Ansible’s new networking automation capabilities, Red Hat is bringing the benefits of DevOps to a new area of IT, and aiming to help customers do a better job with their networks.”

    Joe Hielscher, director of Business Development and Alliances, Arista Networks

    “Red Hat and Arista share a goal of enabling joint customers to focus on improving their businesses, rather than learning complex proprietary tools. Arista EOS and CloudVision, combined with Ansible by Red Hat, deliver standards based tools for datacenter administrators, enabling enhanced operational efficiency and application of DevOps methodologies for cloud networking.”

    Mike Cohen, director of product management, Cisco

    “The trends of cloud, big data, and microservices demand ever increasing speed, scale, and flexibility in network infrastructure. By building on Cisco’s open software architecture and open APIs at the core of our IOS-XE, NX-OS and ACI platforms, Ansible offers our customers an extremely powerful IT automation tool to pave the way for adopting the DevOps model.”

    Brian Ortbals, vice president, Advanced Technology, World Wide Technology (WWT)

    “Ansible is an integral part of World Wide Technology’s network automation strategy. Network automation and programmability using Ansible is a key component of the training curriculum of WWT professional services Cisco ACI deployment engineers. WWT has developed a solution using Ansible to consistently and efficiently configure Nexus 9000 series switches to customer specifications in our Integration Technology Center (ITC). This announcement further solidifies the relationship between WWT and Red Hat to help realize the operational efficiency of #netdevops for our customers.”

    Additional Resources

    Connect with Red Hat

    About Red Hat, Inc.

    Red Hat is the world’s leading provider of open source software solutions, using a community-powered approach to reliable and high-performing cloud, Linux, middleware, storage and virtualization technologies. Red Hat also offers award-winning support, training, and consulting services. As the connective hub in a global network of enterprises, partners, and open source communities, Red Hat helps create relevant, innovative technologies that liberate resources for growth and prepare customers for the future of IT. Learn more athttp://www.redhat.com.

    Forward-Looking Statements

    Certain statements contained in this press release may constitute “forward-looking statements” within the meaning of the Private Securities Litigation Reform Act of 1995. Forward-looking statements provide current expectations of future events based on certain assumptions and include any statement that does not directly relate to any historical or current fact. Actual results may differ materially from those indicated by such forward-looking statements as a result of various important factors, including: risks related to the ability of the Company to compete effectively; the ability to deliver and stimulate demand for new products and technological innovations on a timely basis; delays or reductions in information technology spending; the effects of industry consolidation; the integration of acquisitions and the ability to market successfully acquired technologies and products; uncertainty and adverse results in litigation and related settlements; the inability to adequately protect Company intellectual property and the potential for infringement or breach of license claims of or relating to third party intellectual property; risks related to data and information security vulnerabilities; ineffective management of, and control over, the Company’s growth and international operations; fluctuations in exchange rates; and changes in and a dependence on key personnel, as well as other factors contained in our most recent Quarterly Report on Form 10-Q (copies of which may be accessed through the Securities and Exchange Commission’s website at http://www.sec.gov), including those found therein under the captions “Risk Factors” and “Management’s Discussion and Analysis of Financial Condition and Results of Operations”. In addition to these factors, actual future performance, outcomes, and results may differ materially because of more general factors including (without limitation) general industry and market conditions and growth rates, economic and political conditions, governmental and public policy changes and the impact of natural disasters such as earthquakes and floods. The forward-looking statements included in this press release represent the Company’s views as of the date of this press release and these views could change. However, while the Company may elect to update these forward-looking statements at some point in the future, the Company specifically disclaims any obligation to do so. These forward-looking statements should not be relied upon as representing the Company’s views as of any date subsequent to the date of this press release.

    Red Hat, Ansible and Shadowman logo are trademarks or registered trademarks of Red Hat, Inc. or its subsidiaries in the U.S. and other countries. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

    Contacts

    Red Hat, Inc.
    Anna Eusebio, +1-919-754-4519
    aeusebio@redhat.com