staging-devopsy.kinsta.cloud

Tag: server provisioning

  • Don’t Underestimate the Work

    Don’t Underestimate the Work

    It is relatively common in human endeavor to attempt to figure out how much work will be involved in a project, and be wrong. The more complex the work being done and the organizational system doing it, the further off estimates can be. This was one of the drivers for both Agile and DevOps: to take smaller steps with less dependencies and complexity.

    The complexity problem is true in the path to application release automation (ARA) as well. ARA merges continuous test/continuous delivery with deployment automation, but both of these toolsets are complex and continuing to evolve. When you think about it, it is somewhat amazing that ARA can handle the breadth of functionality it is covering, while both sides are shifting and growing as well as it does.

    Construction Crane
    Construction Crane, compliments of Pixabay

    When you approach ARA, you should make certain you have a handle on the amount of work that it will take to get the system up and running. It’s not simple, even if you’re already using a full CI/CD environment. But it’s worth the work, so here are some of the things to watch out for.

    Multiple Targets

    First on the hit list is on the deployment side. One of the strengths of ARA is the ability to deploy to any environment. The ARA system has to know about each environment in enough detail to enable deployment on it. It must know how to deploy servers, where to get OS, what needs to be added on to the OS, and how to get the application onto these systems. Increasingly, programmable network elements and security configuration fall into this category also. While tools such as Chef and Terraform can help in this regard, if you’re not already using them, they’ll have to be configured if not already, and then linked into your ARA tool. Understanding the path from here to there is critical to early success with ARA.

    Databases

    This is one of the more vexing problems. While most ARA tools offer the ability to configure databases and database connections, your datasets generally don’t hop around so easily. So if you’re testing and deploying on separate networks, you’ll need to make sure that the relevant tables are on those networks. This struggle impacts moves to the cloud, changes from a fully test network to production or any other change that requires the database server be accessible when it hasn’t been in the past. The work to solve these problems is pretty wide. In some cases, such as purely internal or purely cloud, merely routing from the relevant app instances to the database server will do it; but, in the case of across-the-internet changes, it will take a lot more work. Make certain you understand what challenges you will face before moving.

    Tooling Sets

    Much of the external needs of an application are baked into the app build process through tools such as NPM or Git. But those tools don’t cover everything necessary for the entire app ecosystem. Agents, per-tool databases, small tools used occasionally—make certain you have a list of what makes the app work, and make certain they’re configured to be built in by the ARA tool. This sounds obvious, but watching a team learn by trying to deploy and fix broken parts only to do it again is not only painful, it also leaves a “Did we get everything?” impression. I saw one app break on deploy because the team didn’t include curl. Yes, curl in the deployment. Test had it in the environment, production did not.

    Get an inventory of both application development dependencies (libraries, etc.) and deployment dependencies (databases, reporting tools, agents for monitoring, etc.), and save yourself some pain.

    Decrease Your Work by Asking Questions

    ARA gives you a repeatable build/deploy process that can be used to target the environments you need while reducing manual scripting and steps. But before you throw in, sit with your vendor’s tech people and ask them to walk you through stumbling points, they likely know far more gotchas than I do, because it’s their job, and unless you got the new guy for an SE, have probably seen more. And getting ARA up and fully functional quickly allows you to focus on other DevOps needs, such as improving automated testing.

    — Don Macvittie

  • FLAP, Part 3: Full Data Center Provisioning

    FLAP, Part 3: Full Data Center Provisioning

    In the first two parts of this series (Part 1, Part 2), we covered server provisioning and application provisioning. Knowing a bit about each of these tools is useful (although one blog is hardly a thorough evaluation of strengths and weaknesses—I strongly suggest you do more research), knowing how they work together is the point of full layer automated provisioning (FLAP). Automating one or the other helps, but automating both—and integrating that automation—brings us to the level of “Oh, engineering needs a new test environment, and it has to be internal …” and, with a push of a button, it is delivered. That should be the long-term end goal for your organization, so staff time is free to attend to some of the many other issues that plague any given IT organization.

    The thing is, these tools combine in both better and worse ways. Some are designed to work together as if one product; some take some work to get going but the combination adds value once connected; and some combinations are painful to put together and almost never are worth the effort.

    One thing you’ll note is a repeated discussion of OS support for combined solutions. The reason we address it here, even though we have limited words and it’s already been mentioned in product write-ups, is simple: The limitations of these combinations are compounded. That is, if the server provisioning tool doesn’t support Windows, then the complete solution does not, no matter what the application provisioning tool does. This applies both ways, and is an important consideration for most shops, so we mention it here.

    Tools Built to be Together

    First off, we’ll take the easy ones. These are the combinations that were designed to work together, and do so pretty well. They vary in maturity level, but otherwise, they’re good options if they fit into your environment.

    Razor and Puppet

    This is the easy one. Razor was built to be the server provisioning part of Puppet. While the solution set is relatively new, and it shows in the installation phase (which has several manual configuration steps both before and after Razor install), it is maturing rapidly, and the two dev teams work pretty closely together. This is one of only two solution sets that uses a single UI for all provisioning—in this case the Puppet UI. Support for operating systems is broad, including all versions of Linux and Windows to boot. (get it? To boot?) If your data center is highly heterogeneous, or you are already a Puppet shop, it is worth looking closely at this combination. You just have to keep in mind that it is improving at a rapid rate, so those things you don’t like likely will change soon.

    Satellite + Puppet + Foreman

    As of version 6.0, Satellite is a collection of tools knitted together that include Puppet with Foreman. This means that Red Hat has a vested interest in making certain the two tools work well together. And they certainly seem to. While the operating systems support is limited to Red Hat OSes, the solution is pretty rock solid, and like Razor and Puppet, it is improving at a rapid rate since the switch to this new platform. The UI is independent of the tools underneath, and this is the other solution that offers a “single pane of glass” for all installation activities. The one catch with Red Hat, as mentioned before, is that the functionality of underlying systems is only supported when used with Satellite. How that fits into your organization’s plans is up to you.

    Close Enough to be Second Cousins

    There are some combinations that, while not officially interdependent, have a long history of mutual support, and thus make them strong combinations. These tools tend to come with straightforward directions to make them work together, and those instructions generally work well. Once paired, they can manage complete automation in a relatively integrated fashion.

    Note that these combinations are not even a little exclusive. They are pairings the project teams saw made good sense, and have grown out of closeness. Both sides of these solution sets interoperate with other tools (see the next section).

    Ansible + Cobbler

    Ansible and Cobbler both trace their genesis to Red Hat, and they share some employees/team members—and have for a long time. That makes it natural that the two are closely integrated. Before Ansible started discussing all of the other server provisioning tools out there, it already had Cobbler integration.

    As one would expect, there is Ansible setup, Cobbler setup, and then integration. But once combined, Cobbler can do for bare metal, Ansible can do for cloud, and together they provide a full-stack solution. Since both support most operating systems, the final solution does, too.

    Juju + MaaS

    Juju and MaaS have interoperated for a long time. Both are projects of Canonical, so it is no surprise that their interoperability continues. Years ago this author used them together and it was … difficult. But that was years ago, and just in the last year both projects have made strides in documentation and ease of use. Like most solutions in this category, there are separate installations and then integration configuration. Since both support a large number of operating systems, this solution can manage the full data center also.

    Their traditional home, and the one you’re most likely to be comfortable with them in for the short term, is Ubuntu-heavy shops. But they do support most platforms out there, so it’s worth the time to look into them even for non-Ubuntu shops.

    The Extended and Mixed Families

    Then there are the ones that have not forged solid one-on-one relationships, some because they are forging a separate path and some because they want to interoperate with everyone. Note that some of the above systems meet this category—Puppet is integrated with most of the server provisioning tools out there—but due to space considerations, we’re not going to go over those products again here. This list contains both application provisioning and server provisioning tools not mentioned above.

    Chef

    Chef has put the bulk of its focus on cloud and virtualization, with the notable exception to this trend being in AIX, where it does support server provisioning. “The bulk of its focus” is not absolute, though, and that’s on purpose. Chef has had presenters at the annual conference talk about using it with server provisioning tools, so it isn’t unaware of the integrated solution space, just that’s not where their focus has been.

    SaltStack

    The Salt crew is happy to support everyone. While they don’t talk loudly about whom they are integrated with, the product is in use with most major server provisioning tools out there. As mentioned in the SaltStack write-up in part two of this series, cloud integration is pretty broad also, making Salt perhaps the most versatile of the application provisioning tools with regard to full data center automation.

    Stacki

    Originally built to interoperate with SaltStack, Stacki (disclaimer: this author’s employer) has moved on to support most of the availableapplication provisioning tools. The catch with Stacki is that some are supported with sample integrations and video tutorials at the open source layer, while others require a license and engagement of Stacki core engineers to obtain support. So there is a video showing Ansible and open-source Stacki working together and talking about the integration, but it would require a paid license and negotiation to get SaltStack or Chef with Stacki. Because of the way Stacki is designed, it is perhaps the easiest of all these products to integrate—simply add the appropriate “Pallet” and tell Stacki to include it in installations. It is getting the correct pallet that requires licensing for some platforms.

    Conclusion

    Since any server provisioning tool that allows users to customize the install can have the agents for a given application provisioning tool be the last step of a given install, these overviews are at least a little bit arbitrary. To be precise, they are easier to use in the given configurations, but all application provisioning tools can be forced to interoperate with any of the server provisioning tools listed.

    The point of this series was really to help those looking into full data center automation quickly get up to speed on what’s available in the marketplace, and as much information as a few 1,200-word blogs will allow to help shorten the list to ones relevant to your organization. It is by no means complete, and there are issues and concerns with each of the products that only further research will bring to light, so don’t stop here.

  • FLAP, Part 1: Server Provisioning

    FLAP, Part 1: Server Provisioning

    We have reached the state where end-to-end data center provisioning is a reality. It’s early yet, so there is a certain amount of work involved, but today a DevOps team essentially can turn on the automation and move on to other DevOps priorities. It takes some effort, depending upon the solution chosen, but the end result is an infrastructure that provides for installation of operating system (OS), hardware (if needed) and apps, along with configuration of the whole, at the push of a button.

    There are a number of solutions ready for your data center today, and this three-part series will explore them. In the first part, we’ll talk about server provisioning—the part that takes you from uninstalled server or virtual to a functioning OS configured for your environment. The following two articles will cover application provisioning and merging the two to achieve FLAP. (Yes, I made up FLAP. Use it or not, as you see fit.)

    Disclaimer: I work for a vendor in this space. While I do not believe that impacts my objectivity, I will note where my employer is mentioned, and leave it to the reader to decide if I’m blinded to some items/issues based upon my association.

    Server Provisioning: What and Who

    A server provisioning system takes a physical or virtual server from nothing to fully installed OS. This layer of FLAP is fundamental to automating the entire process. If the system has to be installed manually, using tools and scripts to install applications just doesn’t offer the overall benefit as when the entire process is automated.

    For this discussion, we will be sticking with the major provisioning tools out there. To be sure there are more, and I have information about them, but for this short blog post, we’ll stick with the ones that hold something special—market share, history, integrations, associations—that make them a good long-term bet. Our list is alphabetical, and does not show preference by ordering.

    Cobbler

    Cobbler is one of the original server automation tool sets, and definitely has the history and stability to warrant your attention. For shops that use a lot of Fedora and CentOS, Cobbler in combination with Spacewalk is particularly appealing, as we’ll talk about later. Support includes most Linux distributions. Users have created ways to include Windows in the list of installable OSes, but there is not yet an official solution for Windows.

    Cobbler is integrated with Ansible, Spacewalk, Saltstack, Puppet(user created), and older versions of Satellite. There is some amount of concern about Cobbler’s future growth, simply because Red Hat moved Satellite off of Cobbler with release 6.0, though Red Hat still supports Cobbler. It is too soon after the split to predict how this will fall out, but currently it seems to have motivated the Cobbler core team to do more. Users concerned should check GitHub analytics to see what the trends are for committers and commits at the time they are evaluating (good advice for all of these products, but more pertinent for one where there is a question of its future).

    Cobbler’s hardware support is better than most, and in terms of application support it is a pure-play server automation tool; there is no support for applications at all—application provisioning is expected to deal with that aspect.

    Foreman

    Foreman is an open source project that is currently enjoying the sponsorship of Red Hat, but support is not limited to Red Hat OSes. In fact, Foreman will install just about any flavor of Linux, and can target most physical/virtual/cloud platforms. Using WDS, Foreman can also install Windows.

    One of the big strengths of Foreman is its interoperability—it doesn’t much care which application provisioning tool you are using. It is integrated into Satellite (with Puppet), and has support for all of the other major application provisioning tools. This means that no matter what you’re using to get your apps installed, Foreman is worth looking at for getting your servers installed.

    Like most products out there, Foreman provides CLI, API and GUI. They’re relatively stable in relation to the market, simply because Foreman implemented them earlier than most competitors, and is constantly improving them.

    In short, if you are in an environment that has a wide selection of OS, architecture and application requirements, Foreman should be at the top of your short list. For more focused solutions (in terms of OS, whether or not cloud, or application provisioning tools), it makes more sense to compare specific features/functionality with some of the more focused tools in this list.

    MaaS

    MaaS was the sleeping giant of the automation world, but it does indeed look as though it is awakening. MaaS is part of Canonical’s Ubuntu project, so there is plenty of backing, but historically its goals have been modest and its documentation more so. That changed some time over the summer/fall, and MaaS is showing increased support for OSes, better documentation and a more focused attempt to get the word out. If you are primarily an Ubuntu shop, it is well worth considering.

    Like most of the products in this offering, MaaS uses PXE to get the machines into its system, and then uses predefined images that have been imported (Ubuntu images don’t need importing) to install a machine from bare metal/virtual to working OS. MaaS proclaims support for CentOS, RedHat, SuSE, Ubuntu and Windows. For those unfamiliar with the space, that’s an impressive list. But the last time this author used MaaS, it was still only Ubuntu, so I cannot comment on the level/quality of support for each of the OSes. Due diligence should involve testing with those OSes your organization needs.

    The weakest part of some installers is non-standard hardware, such as RAID controllers, specialized network cards and the like. MaaS supports these components and includes UCS support in its packaging. Directly mentioning UCS support is only to be found with MaaS and Stacki, so if you’re a UCS shop, it is worth considering.

    In addition to CLI, MaaS touts an API and a GUI. These are important tools in the DevOps sense, because the API lets you tie MaaS into your automation architecture, and the GUI helps find issues specific to MaaS and its domain. Particularly interesting is the collection of logs that show install results and operations results clearly for each server.

    The one major drawback to MaaS is its limited application provisioning support—it is well-integrated with Juju, but none of the other big names in the space.

    In short, for Ubuntu shops using Juju, this is the tool to put at the top of your short list. For everyone else, the tool is viable, but should be considered against the features/functionality of other tools.

    Razor

    Razor is Puppet’s newer bare metal installer. It is young yet, and there are still issues to be worked out, but the large cadre of developers that are dedicated to Puppet say that Razor will continue to improve as time moves on. At current it directly supports most flavors of Linux and Windows installations. The catch to Razor is on the other end: It is designed to work with Puppet, and support for other application provisioning tools is low—indeed, is limited to user-designed solutions. Needless to say, because it is sponsored by Puppet, it is expected that official work in this area will remain slow, as it is not a priority.

    Razor does not have a dedicated GUI; instead, it uses Puppet’s GUI to report results. As with integration, this is okay for Puppet shops but pretty much eliminates Razor from consideration for other shops. (More on this in a future blog in this series.)

    Because Razor is new, there are a couple of serious caveats with the product. First, install is one of the worst in the market, with a lot of pre-install steps, a lot of install steps, and configuration of an array of underlying systems by hand. Second, each currently installed server that you do not want Razor to re-install must be entered into Razor manually on the command line. This is so limiting in a generalized data center environment (where Puppet shines) that you can expect this limitation to be resolved quickly.

    In short, for Puppet shops that do not see their application provisioning tool changing, this is the tool to put at the top of your short list. For other shops, it’s worth looking at competitors first, simply because Razor requires Puppet.

    Stacki

    Stacki is an open source project sponsored by StackIQ (as promised, this is my employer). Having roots that stretch back more than a decade, Stacki specializes in RedHat/CentOS installations with additional support for clustered software. As of this writing, CoreOS and Ubuntu have been added to Stacki’s list of supported OSes, and expect that list to grow over time.

    The biggest appeal of Stacki is the variety of ways to get systems under management. All of these apps will auto-detect a new server on the network, grab it and install it. Stacki adds the ability to list just the servers that should be clean-installed in a spreadsheet, the next time each of those machines boots they will be installed, but no other machine will. While there are ways in all of these systems to simulate this functionality—you can add exceptions to the “install all machines that boot on this subnet” rule via the command line in Razor, for example—using a spreadsheet to affirmatively manage what machines are to be installed and how gives an offline bulk way of managing installations and re-installations.

    As of this writing, Stacki does not have an API, and only with commercial add-ons can a GUI be had, but expect one or both of these things to change as the community begins guiding development efforts. Stacki is optimized to spin out hundreds of servers in minutes or hours instead of weeks or months, utilizing a peer-to-peer parallel installer to service installations faster as more servers come online. While it works as well as others in smaller environments, it really comes to its own when there are a large number of servers under management. On the initial installation front, while the other systems in this list require hand-installing and/or configuring prerequisites and sub-systems, Stacki comes as an ISO with a UI that asks a few questions and configures everything.

    Stacki has been used with most (Ansible, Puppet, Saltstack) of the major application provisioning tools this series of blogs will consider, making it versatile on the application side of the equation.

    Overall, if you’re a Red Hat shop that uses CentOS a lot—particularly a larger shop—Stacki should be the first stop on your short list. For everyone else, the tool is viable, but should be considered against the features/functionality of other tools.

    Stay tuned for part two of this series, which will cover application provisioning.