devopsy.kinsta.cloud

Tag: vagrant

  • How to Isolate Development Environments: Vagrant vs. Docker

    How to Isolate Development Environments: Vagrant vs. Docker

    “It works on my machine.” This line has become an excuse often overused by developers to escape the burden of having to investigate problems experienced by end users that they are unable to replicate on their development machines. While this may excuse developers—after all, they didn’t experience the problem during development and therefore couldn’t have anticipated it happening to some users—it doesn’t solve the problem.

    Sometimes, issues are caused by end user mistakes, such as skipping a step in an installation process. Often, however, the problem arises from some disparity in the development and server or user environments. With the vast assortment of machine configurations in use—different operating systems, hardware specifications and software versions—even the slightest differences in development and production device configurations can cause dramatic differences in the behavior of many applications.

    This can be a serious issue, as it requires members of the development and operations team to identify the root cause of the problem, which potentially introduces unexpected and often significant delays in deployment and production schedules. Especially in the DevOps culture where rapid development, frequent deployment and highly dependable releases are of highest priority, such unexpected delays are completely unwelcome.

    Thankfully, there are a number of tools that have emerged to address this very problem. In this article, we take a close look at two popular tools with two different approaches to solving the problem of environment disparity: Vagrant and Docker. Like many DevOps tools and technologies such as continuous integration, these tools work well with all types of project setups, including IT outstaffing (dedicated development teams). Let’s compare these two solutions and see which types of scenarios each one is best fit for.

    Vagrant vs. Docker

    Vagrant offers to solve the aforementioned problem by enabling developers to easily create and manage virtual machines (VMs) in which they can develop, test and deploy applications. By using a VM, a developer or DevOps engineer is assured that as long as the application is run within the virtual machine, its behavior will be the same regardless of the actual hardware and operating system of the computer that the VM is running on.

    Docker offers a similar solution, but uses a different technology. Instead of using virtual machines, it uses containers, which are similar to Linux Containers (LXC) that are included in Linux systems. Containers serve a similar purpose as virtual machines, but at a much less extensive level and, therefore, are much more lightweight. Rather than isolating an application in its own virtual computer with a full operating system, containers simply isolate an application inside an environment with the minimum components necessary to run the application. This includes system libraries and tools, settings and configuration files and a runtime environment. Compared to virtual machines, containers consume much less resources from the actual machine on which it is being hosted. Docker has a comprehensive documentation library that includes information on what Docker and Docker containers are, how to install Docker and how to execute a Docker run.

    Vagrant and Docker share some common goals. For instance, in software development, both tools enable a more streamlined and consistent software development and deployment workflow by eliminating the need to worry about the application behaving differently in different machines. Moreover, it offers some degree of security to the host machine: Since the application is isolated from the rest of the system, issues caused by one application should remain within the scope of its environment and should not break the rest of the system.

    There are, however, a number of important differences between Vagrant and Docker that make them suitable for different types of applications. Let’s examine more closely how these two differ.

    Scope of Isolation

    While both Vagrant and Docker wrap applications into isolated environments, they differ in the degree to which these applications are isolated—or, effectively, the scope of the isolated environments. For Vagrant, the scope is the entire operating system: An application can access any and all components of the full virtualized machine and operating system it is being run in. For Docker, on the other hand, the scope is much narrower, as an isolated environment is limited to a single application or service: Each container is created specifically for an application. Effectively, this implies that with Vagrant, a single isolated environment can run multiple applications at once, while with Docker, running multiple applications will typically require the use of a separate isolated environment for each one.

    Resource Consumption

    Since Vagrant virtualizes an entire machine with a full operating system, it naturally has a high overhead cost and consumes a lot of resources from the host machine. With Docker, on the other hand, an app within a container shares the same kernel—the core module or component of an operating system—with both apps in other containers and the host machine itself. This enables containers to have much less overhead and subsequently consume much less resources from the host machines than do virtual machines. In effect, a host machine running apps with containers can run up to three times as many applications as it can with virtual machines. Moreover, since launching apps within containers won’t necessitate having to wait for the virtual OS to boot up, launching apps can also be substantially faster with Docker than it is with Vagrant.

    Limitations

    Vagrant and Docker also have their own limitations. Docker, for instance, is currently natively available to two operating systems: Linux, where it uses the Linux Kernel, and Windows, where it uses the Windows kernel. Docker is also available for MacOS, although it runs Docker containers on top of a Linux virtual machine. Moreover, Docker has some security issues—its use of containers make it less secure than Vagrant. Since applications within Docker containers share the same kernel with each other and with the host machine, it’s possible for a malicious program within a Docker container to affect other containers and even harm the host machine itself.

    While Vagrant, which uses virtual environments, is much more secure in this regard, it is limited in that it is meant only as a tool for development and generally not recommended for use in production environments. In other words, it is meant to provide a convenient way to virtualize the environment of the server to which an application is eventually going to be deployed, but once in production, the application must be run directly on the host machine. On the other hand, Docker provides a consistent environment for applications throughout the entire software development workflow, from creation to production.

    Conclusion

    Being able to isolate applications into their own controlled environments has proven to be extremely useful for software development, as it eliminates many hardware and software incompatibility problems that applications may run into when executed in different machines. This is particularly useful in DevOps environments, as it streamlines the whole software development workflow by eliminating sources of unexpected problems, thereby potentially shortening development cycles.

    We have looked into two popular tools for environment isolation, Vagrant and Docker. Both isolate applications from the host machine, although to varying degrees and using different technologies. Vagrant uses virtual machines, which can support multiple applications at once, but can be heavy on resource consumption and is only recommended for use during development. Docker, on the other hand, uses containers, which support only single applications, but is much lighter in terms of resource consumption and can be used both during development and during production.

    As such, these two tools cater to different business needs. If you require the development of a complex system of multiple applications interacting with each other, using Vagrant may be beneficial, but if you’re aiming to create a single portable application and want to minimize resource consumption, then Docker is the way to go.

    — Myron Monets

  • DevOps Primer: Using Vagrant with AWS

    DevOps Primer: Using Vagrant with AWS

    One of the most common problems in modern software development is the phrase, “It works on my machine,” when a particular piece of code runs on developer’s machine but produces error on other team member’s machine. Thankfully, now there is a plugin that can help determine why something works only in particular environments, turning the phrase into more an observation than an excuse.

    Vagrant to the Rescue

    Vagrant is a tool for building and maintaining portable software development environments. It isolates your project’s dependencies and configuration from your projects without disturbing the tools your application is consuming. You could easily reproduce similar environments on other machines by using the same configuration as your machine.

    Basic Concepts in Vagrant

    Before going further, it is important to understand the following basic concepts that are essential to the working of Vagrant.

    Provisioners

    Provisioners provide automation for installing different software and configurations. It is useful in cases when you don’t want to install software manually to your machine.

    Providers

    Providers provide basic services that are required to run your machine. Although Vagrant provides support for VirtualBox, Hyper-V and Docker, other providers can also be used through appropriate plugin.

    Boxes

    Boxes are Vagrant environment packages that can be copied to any other machine to replicate a similar environment. Vagrant provides a repository of these boxes that can be downloaded, and you can contribute to the list by adding your own customized box.

    Install the Plugin

    The first step in the process is to make sure that you have Vagrant installed on your machine. As I mentioned earlier, you could use providers by installing the respective plugins. For the purpose of this tutorial, I will download the vagrant-aws plugin through the following command:

    vagrant plugin install vagrant-aws

    Next, verify the plugin installation through the command:

    vagrant plugin list

    The vagrant-aws plugin should be present in the plugins list

    Set Up the Vagrant Box

    After installing plugin, the next step is to install a Vagrant box. The problem is that there is no box for AWS provider. To make things work, I recommend you use the dummy box provided by Mitchell Hashimoto.

    Run the following command to add the dummy box:

    vagrant box add aws https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box

    Although I have named the box aws, you can give it any name that works for you. Once the process finishes, I am ready to create AWS instances.

    Create the Instance

    Run the vagrant init command to create a vagrant file:

    vagrant init

    Next, edit the vagrant file as follows:

    # -*- mode: ruby -*-
    # vi: set ft=ruby :

    # Require the AWS provider plugin
    require ‘vagrant-aws’

    # Creating and configuring the AWS instance
    Vagrant.configure(‘2’) do |config|

    # Use dummy AWS box
    config.vm.box = ‘aws’

    # Specify configuration of AWS provider
    config.vm.provider ‘aws’ do |aws, override|
    # Read AWS authentication information from environment variables
    aws.access_key_id = ‘ABCR2NDJKZJIAJ5QVXGJK’
    aws.secret_access_key = ‘WAuZE39lKHXAJnCfbZf2y6DzRfeCsPUU/yZMRDWo’

    # Specify SSH keypair to use
    aws.keypair_name = ‘vagrant’

    # Specify region, AMI ID, Instance and security group
    aws.region = ‘ap-southeast-2’
    aws.ami = ‘ami-14b55f76’
    aws.instance_type = ‘t2.micro’
    aws.security_groups = [‘default’]

    # Specify username and private key path
    override.ssh.username = ‘ubuntu’
    override.ssh.private_key_path = ‘~/vagrant/vagrant’
    end
    end

    Vagrantfile Explained

    The following list explains the important variables and aspects of the above file:

    • config.vm.box : Specify the box. Using dummy aws box for AWS deployment
    • aws.access_key_id : Access key ID of your Amazon account
    • aws.secret_access_key : The secret access key for your Amazon account
    • aws.keypair_name : Your SSH keypair in AWS
    • aws.region : The AWS region in which you want to create your instance
    • aws.ami : The AMI ID you want to use. AMI specifies the information needed to launch a virtual machine within EC2
    • aws.instance_type : The AWS instance you want to create
    • aws.security_groups : Specify the names of security groups that will be applied to your instance
    • override.ssh.username : The username that will be used to access the instance
    • override.ssh.private_key_path : The path of your SSH private key

    Launch the Instance

    After configuring the Vagrantfile, I will simply run the vagrant up command. Vagrant will launch an AWS instance through the AWS AMI provided in the configuration using the credentials provided in the Vagrantfile.


    You can view the newly created instance in the AWS console panel.

    You can now SSH into your AWS instance or perform other Vagrant operations.

    Final Words

    As you can see, using Vagrant to launch a AWS instance is simply a matter of installing the plugin and then launching the instances through easy steps. If you need help with the process, do leave a comment below.

    About the Author / Ali Azmi

    Ali Azmi is Associate DevOps Engineer at Cloudways – A Managed PHP Cloud Hosting Platform. He is skilled in developing PHP applications particularly in Laravel. He is passionate about contributing to open source projects.

  • The Disposable Development Environment

    The Disposable Development Environment

    Wait! Just wait a dadgummed minute! It takes days to build a development environment, and now I am supposed to read an article on a disposable development environment?

    Yes.

    It seems like it took an entire sprint to upgrade PHP! Now I am supposed to let them build something so they can trash it?

    Yes … yes, you are.

    Disposable DevOps Thinking

    DevOps is based on five pillars:

    • Culture
    • Automation
    • Lean Thinking
    • Measurement
    • Sharing

    Because we automate environments such that they are easy to share, we should be able to measure meaningful business impact. This model is a DevOps practice of modeling developer workflow for operational tasks.

    Why a Disposable Development Environment

    Log in to your workstation and delete the runtime for Java, PHP, etc. Remove, or change, a few config files and empty the trash. Now what? What if your entire team did this because they had a great idea? Panicking yet? What if getting started in any team was as easy as:

    • Cloning the project from source control
    • Starting the runtime environment
    • Obtaining caffeine
    • Getting to work

    The majority of developers today have a hand-built, artisanal, bespoke workstation setups with the following characteristics:

    • It takes days to onboard a new team member.
    • Innovation around runtime environments is stifled.
    • Moving from one team to another is the work of days.
    • Workflow is more like Ops instead of Dev.

    Let’s set some goals:

    • No more than 30 minutes for a new team member to make their first code commit.
    • No more than five minutes to throw away an environment and start over.
    • No more than five minutes for a developer to move from one team to another.
    • Runtime changes happen the same way as application changes.

    None of this is possible unless your teams can throw away a runtime environment at will, thus disposability is an “[-ility]” that we should expect to be delivered with our software.

    Disposable is Indispensable

    The most important concept is handling runtime of the application with a virtual machine (VM) on the workstation. The application code remains on the workstation. This means that developers still use all the tools and workflows they have today. If a mistake happens on the VM, kill it and start over. If it happens on the workstation, then its time to rebuild the laptop.

    At its core, the ideas borrows from common concepts in our production environment (and a specific tool example):

    • Hypervisor for supporting guest virtual machines on the workstation, such as Virtualbox
    • Provisioner to configure the guest machine, such as Chef
    • Source Control to track and manage changes to the application and the configuration, such as git
    • Glue so the provider and provisioner can be expressed as code and managed through source control, such as Vagrant

    Onboarding a New Team Member

    Have the new employee follow a set of directions. It should take no more than 30 minutes for the employee to install the tools and the application he or she is to work on. As a manager, this must be measured and tested relentlessly. New hires should be directed to keep notes on trouble spots and anything that takes a long time. They improve the documentation for the next new hire.

    Accelerate Innovation

    Developers say, “I wish I could upgrade to PHP X! I would be done in minutes, not days!”

    Developers are capable of such an upgrade, so the real problems are:

    • It takes a few hours to upgrade a language version.
    • If the attempt fails, it could be longer to unravel all the hand-rolled changes.
    • If the attempt succeeds, everyone on the team is committed to undertake a fraught journey to upgrade their bespoke workstation.

    With management asking about things such as feature velocity, time to value and internal hurdle rates, who is willing to take that sort of time only to succeed and cause everyone else on the team grief, too? This is why security upgrades are always done with such pain. They are delayed because they are “non-functional.”

    Now abstract the runtime to a VM and the configuration of the VM to code. Assume the developer wants to upgrade PHP.

    • Developer destroys the current VM with PHP 5.2.6 on it.
    • Developer goes into the Chef code (for example) and changes the PHP version to 5.3.29.
    • Developer launches a new VM with a single command.
    • Developer runs automated tests.

    The most likely outcome is some tests fail. With a bespoke environment, this is where the upgrade effort stops. Fixing all the tests is a commitment to getting the entire team to move in lock-step. On a team of just five people this is daunting. Developers are not project managers.

    With a disposable development environment, it takes five minutes to make the change. Developers know it is an identical effort for their colleagues, so the thinking changes.

    Given an arbitrary time window, the tests are fixed and the PHP upgrade saves the time or improves system performance or patches a security hole. To share this change across the team this same developer commits the change in the Chef code. They push it to the code repository and message the team, “Hey PHP 5.3.29 works, please adjust.” One person does all the work.

    Team members stop what they are doing. They stash the work they have inflight. They pull the changes from the code repository. They start the VM and Chef configures it. They unstash their work and get back to providing business value. In less than five minutes the entire team is done.

    Accelerate Security and Compliance

    What if a developer’s upgrade causes security issues? Changing something as important as the language version is meant to illustrate this power. But this is not the right question to ask. Instead, ask this one, “How do we ensure we are secure before we get to production?”

    Assume that any change in the development environment is reflected in production through the same process. For example, when code is deployed to quality assurance (QA), the Chef cookbooks run and they bring up the machine with the new PHP version. Why would there not be tests to show that the application is at least as secure as previously?

    Even more to the point: By making it easy to upgrade the base language, test the change and share it across the team, upgrades are much less risky.

    This thinking has some new assumptions:

    • You trust test automation at the application level. (common)
    • You trust the test automation at the infrastructure level. (uncommon)
    • You have automated security and compliance practices that check before a production release. (rare)

    As managers we must help our:

    • Ops team becomes better at the practices of code management since the infrastructure will be code.
    • Development team makes responsible changes in concert with operations, security and compliance groups.
    • Security teams adopt a security-as-code mindset to facilitate testing before promotion from development.
    • Compliance team joins the development effort so changes are already part of audit output. Compliance-as-code is already on the way.

    Business Outcomes of a Disposable Development Environment

    We hire new people when we need them. Taking two weeks just to get into a working state means we are delaying time to value. Delaying 30 minutes is less time than filling out the HR paperwork. We need this critical time to fill the need that caused the hire.

    Developers have more freedom in the infrastructure to try their ideas. The also have the safety net of putting it back like it was in less than five minutes when the idea does not pan out.

    Patches to the runtime environment for security can be applied at development time where they can be tested through the full deployment cycle. This takes minutes instead of days.

    If all teams are using a standard method and tool chain, then it is possible to adhere to the maxim, “Put your best people on your biggest opportunity.” Developers can move from Team A to Team B in less than five minutes and get started learning the code. They can move back in the same five minutes.

    Changes in the runtime happen at development time, and they are promoted and release with the application. So, perhaps most of all, if it works on the developers laptop then it will work in production.

    Without the ability to simply throw away the environment and easily start over, Dev and Ops cannot innovate toward these benefits. So go ahead and dispose of those bespoke workstations, and be sure to manage toward the benefits:

    • No more than 30 minutes for a new team member to make their first code commit.
    • No more than five minutes to throw away an environment and start over.
    • No more than five minutes for a developer to move from one team to another.
    • Runtime changes happen the same way as application changes.
  • Agile Infrastructure: Because your Infrastructure Deserves Tests, Too

    Agile Infrastructure: Because your Infrastructure Deserves Tests, Too

    Editor’s Note: This post was updated Aug. 4, 2018, to reflect an updated slide presentation at the end of the article.

    Infrastructure as Code is a truly powerful concept whose significance is best described with the words of Adam Jacob, CTO at Chef, in Web Operations: Keeping the Data On Time: “Enable the reconstruction of the business from nothing but a source code repository, an application data backup, and bare metal resources.” And so it’s not for nothing that treating infrastructure as code is regarded a key principle for reducing cycle time and maximizing flow in Continuous Delivery and DevOps, respectively. Even if your plans are less bold as you read this article, wouldn’t you agree that consequent validation of what you automate on the infrastructure level — long before it goes into production — would be extremely powerful?

    So, bear with me for a while and please don’t rush head over heels into automation by simply picking one of the established infrastructure automation tools such as Chef or Puppet, getting everyone trained in Ruby, and blindly start to “automate all the things”. If that’s how you do it, then you are most probably doing it wrong. In You’re Doing DevOps Wrong. Automation in the Enterprise., author Alan Sharp-Paul suggests that, before doing any automation, you first have to understand precisely the requirements and how to validate them to gauge success and maintain quality of your automations over time:

    • Are the configuration files in place? Do they contain the right settings?
    • Is this port open? Is that port closed?

    Why Agile Infrastructure?

    Honestly, you and I wouldn’t expect anyone to come up with reliable software merely by choosing an arbitrary programming language and a nifty IDE without having some sort of engineering process in place, right? Likewise, the (automated) provisioning of a solid production environment demands a no less methodical approach. Luckily, Infrastructure as Code enables us to treat the provisioning of infrastructure as well as automating deployments and configuration as an Agile engineering discipline. Although the concepts of Agile Infrastructure are not entirely new, testing against live infrastructure has only recently been facilitated with the consolidation of tools such as Ansible, Chef, Puppet, Docker, Vagrant and Serverspec under the hood of Test Kitchen (see more on that below). Here are some of the key implications of applying Agile software development practices to the infrastructure level:

    Alignment of Devs and Ops

    Agile software development teams are driven by customer demand and aim to produce outcome in short, regular intervals. Enabling IT Operations and Infrastructure departments to work in small iterations and react to changes quickly allows them to align with and effectively become driven by software development. The outcome of these joint efforts will be both working and deployable software at the end of each iteration.

    Fail Fast: Feedback Loops

    Executing infrastructure tests as part of your Continuous Delivery build pipeline (before an application is deployed and long-running tests are executed) establishes another important feedback loop that enables you to “fail fast” and get the right people involved. The underlying principle is simple: by expressing your intentions twice — once in the code and once in a test — you’ll know you’ve caught a bug whenever these assumptions don’t match.

    Regression Safety

    Believe it or not: whether you are using Ansible, Chef, Puppet or any other — you’re running on code! Their respective issue lists are full of unresolved issues of various severities with new issues coming in regularly. Having a sufficient safety net of tests for your infrastructure in place allows you to quickly identify bugs as they creep in (from either side) and protects you against unwanted regressions. After all, a bug in your infrastructure can be very hard to track down and can be much more severe than a bug in your application.

    Refactoring

    Code refactoring becomes a breeze when you have tests in place that immediately alert you when you broke the desired state of your infrastructure (and all you wanted was to make your code simpler and more maintainable). This is invaluable when you want to recompose your existing infrastructure from 3rd-party components offered on public hubs such as Ansible Galaxy, Chef Supermarket or Puppet Forge, and especially when you are migrating away from your existing automation stack.

    The Red, Green, Refactor Cycle of Test-Driven Development

    Test-Driven Development (TDD) is a popular software development process that involves writing code in short, repeating development cycles with the goal to enforce good design and enhance confidence. While it is certainly no silver bullet and has been controversially discussed in the past, the Red, Green, Refactor Cycle, which is at the heart of TDD and whose principles I want to quickly summarize here, hopefully gives you some inspiration on how to incrementally build up your infrastructure:

    1. Red: Understand the requirements and the state you want to implement. Then think about how to capture this state in a test. Implement the test, then run your entire test suite and see the added test fail — and if it doesn’t, something is really wrong.
    2. Green: Implement just enough functionality to make the test pass. Don’t care much about readability, simplicity and design for now — just make it work. Run your tests again and watch all tests pass. If they don’t, either fix your test or your implementation, or take a step back (revert to a point in your code that’s known to work) and start over with a smaller increment.
    3. Refactor: Now that your tests pass, improve your implementation and make sure, by running your tests again, that you didn’t break anything. Once you are done refactoring, start the cycle over again.

    Keep in mind that each repetition of the cycle refers to a small increment. In terms of infrastructure, such an increment could be the installation of a user, a package or the placement of a configuration setting. When you arrive in a spot where you broke something, you can easily revert to a point in your code that’s known to work. Leveraging such practices really makes the difference between Infrastructure Automation and Infrastructure as Code, as described in Infrastructure as Code – Automation Is Not Enough by Keith Morris.

    Test Kitchen, Terraform, AWS and awspec

    Now, how to get there? Test Kitchen is an easily extensible test harness that allows you to test your code written in Ansible, Chef, Puppet (and others) on various cloud providers, virtualization providers and operating systems with tests written in a variety of test frameworks.

    In the following presentation, I give hands-on examples for you to quickly dive into the topic of using Test Kitchen with awspec as a framework to test Terraform deployments on AWS:

  • Road to Modern Ops

    Road to Modern Ops

    This is the first lesson in HashiCorp’s Road to Modern Ops, an interactive curriculum dedicated to guiding organizations from manual processes to modern, automated operations. This essay sets the foundation for the curriculum by outlining manual operations tasks and the path towards automation. To put this knowledge to work, explore the interactive tutorial to learn how to manually manage an operations workflow.

    A letter to operators, sysadmins, and devops-ers: don’t lose sight of operation’s end goal. The goal of operations is to turn application code in development into a running application on a production server through a safe, error-free process. This is done in three general steps — server provisioning, server configuration, and application maintenance. Over the past few months and even weeks, there have been a mass of technology announcements relating to these three steps and the operations space overall — new container technologies, minimal VMs, configuration management tools, monitoring tools, automated provisioning tools, service discovery systems and more. As a result, the operations industry has gotten caught up in these details but lost sight of operation’s end goal.

    The technologies in the operations workflow are prone to change, as shown by the past few months. However, the operations workflow itself – moving an application from development to production – is unlikely to change in the near term. The main advancement in the general operations workflow is the rise of automation to replace manual tasks. This is often referred to as “DevOps” (one of DevOps’s many interpretations). Modern workflows embrace automation to reduce human error, scale deployments with the same number of operators, and increase transparency across the process.

    While most organizations have the same end goal of an automated, error-free, and quick operations workflow, it’s confusing how all the different operations tools fit together to accomplish this goal. How do Jenkins, Chef, Vagrant, Docker, Terraform, Datadog, etc relate to each other? How can they be used to build an automated deployment process? The transition from manual configuration, provisioning, and service discovery to fully automated, modern ops is an unclear path.

    The road to modern ops — automation and the modern datacenter

    “Road to Modern Ops” is an interactive curriculum by HashiCorp to guide organizations to modern, automated operations through a gradual and detailed educational process. Each lesson takes a manual process and demonstrates how to automate it through an interactive tutorial. By the end of the curriculum, participants will understand the components of operations, how to automate those components, and finally how to combine the components into a fully automated application delivery workflow.

    The first tutorial lays the foundation for the curriculum by walking through manual configuration, provisioning, and maintenance. Subsequent lessons automate one component at a time, and then unite them to form a cohesive, automated operations workflow. The goal of the curriculum is to not only provide hands-on experience with automation, but to understand how the tools fit into the larger operations ecosystem. Start on the road towards modern ops.

     

    atlas-hashicorp-com-road-to-modern-ops

     

    About The Author  ⁄ Kevin Fishner

    unnamedKevin Fishner is the Director of Customer Success at HashiCorp. He has extensive experience working with customers across HashiCorp open source and commercial products. Philosopher by education (Duke), engineer by trade. Connect with Kevin on twitter.

  • HashiCorp unites open source DevOps tools with Atlas

    HashiCorp unites open source DevOps tools with Atlas

    Open source and DevOps go together like chocolate and peanut butter, or like milk and cookies (these metaphors are making me hungry). Basically, they’re inseparable and—while each is good in and of itself—they’re better when united. HashiCorp announced today that Atlas, a platform for a variety of leading open source tools, is now available to the general public to help organizations make DevOps even better.

    HashiCorp has a number of popular, industry-leading open source tools at its disposal. Vagrant manages development environments. Packer automates building artifacts like Docker containers, OpenStack images, and VMware images. Consul is a tool for runtime orchestration. Serf is a protocol used by Consul for failure detection and message distribution in a server cluster. Terraform automates infrastructure provisioning on cloud platforms like Microsoft Azure and Amazon Web Services. They’re all great tools in and of themselves, but Atlas ties them all together into a powerful, cohesive whole.

    Atlas has been available in beta for a while with tremendous success. Nodes under management consistently doubled month-to-month during the beta, and heavy hitters like Mozilla and Cisco jumped on board to test it out.

    DevOps seeks to accelerate development and deployment. One of the primary attributes of DevOps is automation to facilitate automatic, error-free, auditable implementation of routine, repeatable functions. Many organizations strive to embrace DevOps tools and principles and leverage open source tools like Consul or Vagrant but use manual, time-consuming, error-prone processes that are difficult to scale and challenging to manage effectively.

    HashiCorp believes that Atlas is the solution—a platform that brings it all together and enables organizations to manage end-to-end from configuration management to container deployments across multiple cloud environments. Each of the open source tools is fine alone, but the ability to manage and orchestrate them as a whole is very powerful.

    “We initially rolled our own solution for infrastructure CI and deployment. As the team grew, our homebrew solution struggled to centrally manage configuration, Terraform state, and access control,” said Chris Lonnen, Internal Tools and Systems Architect at Mozilla. “Atlas remedies all of these challenges for us and provides a beautiful interface for audit logs, infrastructure history, system-wide monitoring, and more. We’ve never lost 9s betting on a HashiCorp product.”

    According to the HashiCorp press release, you can start using the hosted version of Atlas as of today, but on-premise deployments of Atlas won’t happen until late 2015. If you want more information about on-premise Atlas you can sign up at this link: https://atlas.hashicorp.com. The development features like Vagrant box builds and hosting and Packer builds and artifact storage are free, and the first 10 nodes are free as well. Pricing is $40 per node per month beyond the first 10 nodes.