Category: Blogs

ElasticBox Jenkins Plugin – Easy Continuous Integration Setup

Introduction to Jenkins and ElasticBox

ElasticBox has recently released a Jenkins plugin which makes it possible to configure a continuous integration or continuous deployment scenario without writing any code or scripts! How have we done this you ask? Simple, it was magic. In all seriousness, magic is the end result if you integrate ElasticBox and Jenkins with the source control software of choice.

For those who rely on Jenkins for daily work, performing integration builds, orchestrating complex, large scale scenarios for testing or managing continuous delivery of applications with many configurations across multiple environments, is not uncommon. These types of scenarios require a lot of time setting up slaves and performing manual steps to configure the provisioning of cloud providers. Keeping consistency and across the environments becomes exponentially complex when you factor multiple clouds or hybrid cloud environments into the picture.

You can reduce the amount of manual configuration and scripting, while abstracting the provisioning of infrastructure, by using ElasticBox with the ElasticBox Jenkins Plugin. This means that you can use ElasticBox to solve complex continuous integration or deployment use cases in the quickest, most consistent and reliable way possible.

How Does It Work:

Here at ElasticBox we trigger tests, builds, and deployments on pull requests and merges, which is a very common use case. These actions start workflows that result in Jenkins triggering tests, builds and the deploying of instances. For more information on our internal continuous deployment scenario, take a look at this slideshare deck we presented earlier this year.

The first thing to understand is that we manage Jenkins as an instance that we deploy into our private datacenter through ElasticBox. We have a single Box that installs Jenkins Server on the provider of your choice. This makes it convenient to scale when multiple builds are slowing things down or to simply redeploy if something breaks all together.

The second piece of the puzzle are the required plugins, like the recently releasedElasticBox Jenkins Plugin, which, along with the Github Jenkins Plugin, makes it entirely possible to set up a continuous integration or deployment server without writing any code.

Setting Up Jenkins and ElasticBox:

First you have to set up ElasticBox as a cloud in the configuration page of Jenkins. You simply enter the ElasticBox url (http://elasticbox.com), a maximum number of instances, retention time, in minutes, and your ElasticBox username and password. Once all this information is entered correctly, you can go ahead and then test the connection.

ElasticBox Jenkins Example:

In this basic example, we’ll show you how we test changes to our website. When a branch is submitted as a pull request, we deploy a new staging instance of our Website Box. We validate the changes on an instance that is a replica of our production environment before merging the pull request into our master branch. When the code is merged, we then trigger a Jenkins job that reinstalls our production instances with the latest code changes (not shown in this demo). Now, our workflow for website changes is almost fully automated, minus the pull request and merge!

1) The first step is to create a new Jenkins item where we select “Build a free-style software project”

2) Once we’ve created a new item, we add the Github project URL and check the ‘this build is parameterized’ box. While this step isn’t required, it allows you to trigger a build manually and execute code from a specific branch.

3) In the source code management section, we specify the source code management tool, the ‘Repository URL’, provide credentials in the form of Username / Password, and for the Branch Specifier, use ‘${sha1}’ which represents the commit url of the branch submitted in the pull request. The Jenkins Git plugin is extremely complex and we highly recommend reading the Wiki on the plugin.

In the Build Triggers section, you’ll want to select “Github Pull Request Builder” Which is what will be triggering the Jenkins build and instance deployment in ElasticBox.

4) The final step is configuring the Build steps. With the ElasticBox plugin, you’ll have access to all your workspaces, boxes and deployment profiles. For more information on each of these features, please check out the links to our documentation. Specify the Workspace, the Box and the Deployment profile you would like to use. In our case, we specify our Production Workspace, our Website Box and our Staging Deployment Profile.

Conclusion:

Once all these configurations are set, you can test changes on new staging instances just by submitting pull requests. Even though this is a basic example, by continuous integration standards, you can see how the ElasticBox Jenkins plugin can seriously reduce the amount of configurations required to setup a continuous integration server.

With ElasticBox abstracting the infrastructure provisioning and allowing you to reuse existing application or infrastructure components, it’s much easier to scale the process in a repeatable and dependable way. We’ll be following up with blog posts that provide more technical examples on how to use Jenkins and ElasticBox for integrated builds, testing and continuous delivery models.

July 15, 2014

DevOps Days Tel Aviv Strikes Again

It’s no secret that the technology scene in Israel is at the forefront of innovation, and so it’s certainly no surprise that the DevOps community in Israel is simply booming. And well, it’s that time of year again, and me and my awesome co-organizers have rolled up our sleeves and started working on DevOps Days Tel Aviv.

This is my third DevOps event that I’m helping to organize in Israel, on top of our regular DevOps Israel meetup group that too has been growing and has had the pleasure of hosting some exceptional speakers (including the brilliant Kohsuke Kawaguchi at our next event).

So it is with great excitement that we have opened the call for papers for the next DevOps Days, and have already started receiving really awesome submissions.

The constant growth in interest and enthusiasm around these events has stunned even us. With the awesome speakers that came out at our previous events – John Willis, Stephen Nelson-Smith, Ben Kepes, and the caliber of speakers who have already submitted for this event – Yossef Mendelssohn, Julia Ferraoili, Michael Ducy, and many more in the works.

The event this year will be taking place September 28-29^th, and we expect it to be even better than the last two.

Registration is officially OPEN. There are only a few early bird tickets available – so get ‘em quick.

You are more than welcome to submit your proposals for talks, ignite talks, and workshops here.

And as with all DevOps Days events – these are completely voluntary, and highly dependent on sponsorship – so if you’re interested, below you can find all the information you need, and you are more than welcome to reach out to the organizers of the event.

Sponsorship Packages

Included in Package	Silver 1000 USD	Gold 3000 USD	Platinum 4500 USD Two Available
2 Tickets
Logo on event website
Logo on all email communication
Mention via Social Media
5 minute pitch to full audience (including streaming audience)
2 additional tickets (4 in total)
4 additional tickets (6 in total)
Shared table for swag
Booth/table space
Lunch or After Party Sponsorship (1 Each)

We’d love to see you at the event. Reach out to us if you have any time @DevOpsDaysTLV

July 14, 2014

Mixed Martial DevOps vs.The Scrum Master

Royce Grace won the most tournaments in UFC history before he retired. With a record of 14 wins, 2 losses, and 2 draws, it’s understandable why he’s considered by some to be the most influential figure in the history of modern MMA. With 100% of his finishes from submissions, he’s undeniably Brazilian Jujitsu royalty. You’d be hard pressed to find anyone familiar with the fighting world that would argue against building a strong base in BJJ while learning to fight. Royce proved that BJJ was the single most effective form of fighting in the early nineties by submitting opponents much larger than him, like Dan Severn, in UFC 4. Severn had just shy of a 100 pound weight advantage on Gracie but ended up getting caught in a triangle choke. I can remember watching the video and trying to figure out how he made him tap like that. All the sudden fighting wasn’t just about kicking and punching anymore, the game had changed forever.

Fast Forward 12 years to UFC when the Master Royce Gracie is to make his return to the octagon. Matt Hughes crumpled him up like a paper napkin. Royce had continued to practice BJJ since his fight with Dan Severn as it was a successful strategy. The mistake he made was investing in a monoculture. Royce kept a razor point on his BJJ, but fighters like Matt Hughes were smart enough to put an edge on all the dull perspectives of their game. Hughes was a well decorated submission wrestler that knew he needed to work on his striking and maintaining his strength and endurance. Ronda Rousey made it clear after her last victory that she’d been working more on her striking too, which makes sense considering she’s already an Olympic medalist in judo.

At the end of the day it’s a fighter that wins a fight, not the discipline they practice. A well rounded fighter is going to be able to adapt to adversity better than someone that only has nth level experience in a particular area. The same is true for software methodology. A scrum master’s team will consistently be outperformed by a team taking a mixed approach. Not because something is inherently wrong with scrum, but that people get the work done, not the process. A team embracing a diverse approach is more likely to do what works. They will be open to more experimentation to figure out what is successful and to confirm when the current model isn’t working. Sometimes it’s the people not cooperating, but telling them there’s a problem because they’re not fully embracing the methodology is usually wrong. Often enough the methodology is being taken as gospel and is embraced too tightly.

I both like and understand kanban, but feel scrum has too much convention to adhere to specifically. I checked Google and it seems to agree with me:

Just to be fair, I checked to see how Google felt about kanban.

But Google didn’t seem to treat kanban as harshly.

If you can’t take my word for this maybe you’ll listen to someone else?

Just the other day Andrew Clay Shafer posted this on Twitter:

I did ask Andrew to offer an alternative approach if scrum wasn’t going to work, and he directed me to slide 46 of a presentation he did in Pittsburgh for a Ruby User Group (shown below). This slide advocates a mixed approach as well. I agree with everything Andrew encourages there, and can honestly admit I need to dig into XP technical practices a little deeper myself. This will not be an abandonment of current methodology and a complete shift in another direction, but an evaluation to see if I can fill some holes in my game.

July 14, 2014
Deploying a MongoDB Cluster with ElasticBox

Our founders, back in the day, were part of the .NET framework team at Microsoft. So it’s no surprise that their first version of ElasticBox was written on C#, .NET framework and SQL Server.

Fast forward to 2012. As the ElasticBox vision crystallized, we wanted a robust, scalable architecture to match our vision. So we reevaluated all the existing technologies.

Among other things, we decided to move from a relational database model to a document based approach. The main reason was because we wanted to store hierarchical data and be able to version it.

Today, to accommodate our data needs, ElasticBox relies on MongoDB clusters, which we run on three separate providers–two public, one private. Thanks to ElasticBox, we can now deploy our MongoDB cluster in a matter of minutes.

The Basics

What is MongoDB? MongoDB is an open-source document store database.

Why would you want to cluster MongoDB? To provide redundancy and high-availability for production deployments.

How We Use MongoDB

In our case, MongoDB is using a replica set model. A replica set is a group of MongoDB instances that host the same data set. One MongoDB, the primary, receives all write operations. All other instances, secondaries, apply operations from the primary so that they have the same data set.

The primary accepts all write operations from clients. Replica sets can have only one primary. Because only one member can accept write operations, replica sets provide strict consistency.

Deploying MongoDB through ElasticBox

ElasticBox provides a default MongoDB box that’s available to the public. It deploys a standalone instance of the MongoDB server. Our MongoDB production box very closely resembles the default box, minus a few configuration settings required for our production scenario.

While the default MongoDB box configuration is suited for development purposes, it needs to be configured further to use in production. To configure the MongoDB default box for production use, follow the steps below:

Step 1. Create a new box called MongoDB Replica. Add a box variable for the MongoDB Server (this is to use the default box settings).

Step 2. Add a text variable REPLICA_SET to hold the replica set name. This value must be shared between all the members of the cluster.

Step 3. Expand the MongoDB Server box. Edit its file variable COMMON_YAML and paste the following:

mongodb::replica_set: {{ REPLICA_SET }}

mongodb::key_file: /etc/mongod.key

This file will be used by hiera to pass arguments to puppet automatically without modifying the existing puppet default.pp file.

Step 4. Add a binding named primary of type MongoDB Replica (the box you just created).

Step 5. Add an install script. Get the script here.

Step 6. Add a start script. Get the script here.

When you deploy the box without a binding, it creates a cluster for you with an initial configuration. On the other hand, if you bind to an existing instance, it adds the instance to the existing cluster!

There, you have it, a MongoDB cluster in a few easy steps!

July 11, 2014
Provisioning versus Configuration

There’s a ton of hype and excitement surrounding containers, a la Docker, today, much in the same way virtualization took the data center by storm. In both cases, the excitement for operations focuses on the ease with which infrastructure might be deployed and managed via such technology.

Whether container or hypervisor, however, there remains a distinct difference between server and network virtualization that must be considered before getting too excited about the possibilities.

There are two distinct use cases for which virtualization and containerization of anything are considered beneficial: scale and deployment.

Scale

In terms of scale, both virtualization and containerization are excellent technologies. Both can fully encapsulate a service – whether application or network – and enable rapid deployment of multiple instances of the same service with very little (if any) post-provisioning requirements. This is the premise upon which cloud computing and NFV is based: clones of services and applications rapidly deployed to enable elastic scalability that matches demand.

For scalability purposes, virtualization or containerization of services is a match made (mostly) in data center heaven.

Deployment

Enabling rapid deployment of new services using virtualization or containers, however, is not necessarily going to net the same benefits. It is important note that the standardization and APIs associated with virtualization and containers that enable scalability so seamlessly is focused solely on the management of the container or virtual machine. The ability to provision a virtual machine or container is not at issue; APIs enable the rapid provisioning of a container or virtual machine with extreme alacrity.

What those APIs do not do is enable the rapid configuration of those services once provisioned.

Configuration != Provisioning

This is a critical differentiation that must be made lest we assume we can leverage virtualization and containers to enable a self-service style data center, a la IT as a Service. While virtualization and containers make provisioning a service instance a relatively painless experience, configuring those services must still be accomplished. When deploying a new service, existing configurations will not be wholly valid. There will always be some amount of customization that must occur, if only to make sure the service is interacting with the right application.

This means that once provisioning of the service is complete, there is still work to be done. One does not simply launch a load balancing service, for example, without instructing it how to distribute load (what algorithm to use) and to what set of servers (configure a pool).

It is important to recognize the difference between these two steps in the deployment process and take into consideration the impact of configuration after provisioning on that process. Depending on the method of configuration, this step can have a serious impact on the speed and efficiency of the deployment process as a whole.

It is also important to note for monitoring purposes, as virtual machine health and status is not the same as the health and status of the service, whether that be an application or a network service. Both must be monitoring and managed in a virtualized infrastructure to meet MTTD (mean time to detection) and MTTR (mean time to resolution) objectives.

In most cases, the impact from configuration is the greater of the two, with its time requirements most significantly impacting the application deployment lifecycle. It is optimization of configuration processes, not provisioning, that will ultimately provide the biggest benefits for DevOps in terms of reducing errors and improving time to market.

July 10, 2014
You can’t automate relationships

As an organization sold on the idea of DevOps what’s your first step in the journey?

Despite a constant deluge of well-reasoned guides for implementing DevOps the most prevalent step most companies have made is simply contributing to a proliferation of DevOps job titles.

Most likely it’s in no small part because asking the HR department to add “DevOps” to the latest sysadmin job posting title and “Chef” or “Puppet” to the requirements is easy. This is a woefully low bar to set for DevOps implementation. Compounding this further, afterwards when the CIO gets a survey asking about DevOps adoption, they gleefully indicate the company is well on their way and join many others as they artificially inflate industry statistics of a very worthwhile but nonetheless major undertaking for large companies.

Surveys can contribute to confused starts. Any survey that does not include questions on specific practices and draws its conclusions from simply asking if a company is doing a practice that has positive buzz in the industry is worthless. A welcome contrast is the Puppet Labs 2014 State of DevOps report which is quite a beneficial collection of supporting information covering various practices, recommendations and nuances of organizational structures.

Even actually making progress on an individual automation project, whether with newly titled DevOps members or from a grass roots effort in an existing engineering or operations team, does not fulfill a complete implementation strategy nor is it the best way to start. Automation is certainly vital to reliably and repeatably managing environments, but groups shouldn’t rush to tackle automation first only because it’s comfortable to start hacking away at a problem they think they can deal with on their own.

These isolated and well-intentioned practitioners may find that without buy in and solid trust and relationships across groups they may not be given access to automate and orchestrate certain key areas.

You can’t automate relationships!

There needs to be a holistic understanding of the value streams driving engineering work and how best to make improvements. Instead of diving headfirst into automation work on identifying common goals, shared pain, and potential wins across organizational groups. Starting either with collaboration between group members directly or through management level alignment can work provided the other quickly follows. Buy in is required from both engineering and management or progress will stutter.

Taking people through a story can bring support more readily than just listing bullet points. People need to feel emotionally engaged and connected to the pains of the culture and process prior to DevOps and how they can be realistically mitigated. For a large company audience, seeing a story from another large company with timeframes and phases that shepherd the transformation in bold, yet manageable steps can be helpful. The story of SAP Global IT is a candid and useful case study.

Once the stage is set then tackle automation together in a cross-functional group with shared measures of success leading your focus. Depending on the complexity of your process it may be beneficial to collaborate on a smaller application or time boxed simple proof of concept to vet new ideas and working relationships.

Despite the potential for rocky or inefficient starts, the transformative power of a meaningful DevOps implementation contributes to incredible innovation speed and satisfaction. What has worked to keep your organization keeping the long view in mind regarding DevOps?

Many companies are misappropriating the term DevOps to get attention, headcount, or perceived leverage in internal turf wars instead of building a cross-team continuous improvement engine. Is this a sign of the early peak of inflated expectations in the hype cycle?

Are we heading for a serious backlash? Is the tireless promotion of proper practices from prolific thought leaders enough to make failures clearly misguided implementations and not fundamental flaws in the movement?

I’m eager to hear your thoughts in the comments.

July 9, 2014
Coaching DevOps Baseball

Coaching DevOps Baseball

Every technology gets surrounded by hype during its maturation, and DevOps is certainly not immune to that phenomenon. If you’ve spent more than five minutes looking into it, you know that, because the current discussion sounds something like this:

“All right, there’s other stuff, but it’s just support, so I want you all to go out there and practice the important part! You only win the game if you score runs, and you only score a run if you run from third to home, so get out there and run from third to home! You’ll be the best team ever on the only part that matters, running it in!”

“What? That hitting the ball and making first, second, third base? That’s supporting stuff, doesn’t really matter, master running from third to home, that’s how you score runs, and runs win games! Oh sure, some hotshot can hit a home run, but then the team relies on the guy who can get home runs, so forget about it, just focus on running third to home!”

Yes, the vast bulk of punditry sound like this right now, and yes, it is as damaging to your DevOps efforts as this coach would be to a baseball team.

And yes, you need to care about all the other parts of the game – because it isn’t baseball if you only do one part, and it isn’t DevOps if you only do one part. No matter how much the coach thinks that part is the important part. After all, in the game, you’ll never get the chance to run third to home if you’re not able to handle the preceding parts of the game.

So when you read pundits at the moment, pay more attention to what they minimize than what they consider the end game. The benefits of putting scripts and configurations into version control, building automated testing, taking the time to write automation scripts you’ve been thinking about off and on for years (and putting those into VC also), all of these things are not only necessary prerequisites to the nirvana some foresee if only you do DevOps “right”, but they also hold benefits all their own. Harness your hotshots to automate what’s hard, and make that automation adaptable enough that it can change with the times. The “right” way to do it is methodically. Indeed, I would add the Etsy slogan “measure everything”. You can’t tell how DevOps is impacting the org if you’re not measuring things.

And doing it methodically is actually pretty easy. Pick a team or (my preference) a project, and tell them to do it. Set standards for keeping each change to configs in version control, demand that they automate as much as possible, but leave points in the process for human checking, require that automated tests are complete and run successfully before the code is considered complete (and set a standard for maintaining tests in the future, since that’s where most orgs have issues). Involve security deeply, because a failed drive, or a server dropped from a bad config can be recovered quickly, a security breech not so much. Then take what you learn, and apply what works well for your org again, perhaps to a larger team or project.

The whole point of DevOps is to improve IT’s responsiveness to changing business needs, increase operational capacity, and reduce human error. It’s not to achieve some goal set by people outside of your org, it’s to do it within the confines of your org.

So go hit some home runs, run the heck out of the first three bases, make IT more efficient and effective. Worry about things like “IT Transformation” when they come up and make sense, not when you’re just learning the rules of the game.

July 9, 2014
The Delivery Pipeline is your DevOps Signature

Where is DevOps? Searching for it is like querying a rainbow for pots of gold. No single element in a development team’s lifecycle defines them as a DevOps-enabled organization. Were anything the rainbow and the gold, it would be the delivery pipeline. The deployment pipeline centers the team and the process, functioning as the signature of any DevOps shop.

(more…)

July 8, 2014
Part Dev, Part Ops

July 7, 2014
Building Security and Compliance into the SDLC

As the concept of DevOps has become more popular in recent years, there are some common themes that always seem to come up in discussions about it. For example, how often do we talk about ways to speed up the software development life cycle (SDLC) in order to bring innovative applications to market faster and meet ever-increasing customer demands?

As important as this and other popular DevOps themes may be, though, they often have the side effect of overshadowing some of the less glamorous topics, such as security and compliance, which is often viewed as a sort of “necessary evil.” That said, the risks of putting an unsecure application into production can create massive challenges for organizations – from breaches to loss of company IP to brand damage – making security and compliance a topic that must be tackled as enthusiastically as accelerating innovation.

Three Critical Areas of Focus

When it comes to considering how security and compliance can become more integrated with DevOps practices, there are three critical areas on which all organizations should focus: shifting security left in the SDLC, building security into policies and creating an audit trail throughout development.

Shifting Security Left in the SDLC

Organizations that incorporate security in the earliest stages of the SDLC will ultimately benefit from products and applications that are secure by design. But in order to accomplish this, they can’t wait until the software hits production to test it for vulnerabilities.

Service virtualization can help by simulating the application delivery run-time environment and its data, allowing developers and testers to focus on security immediately, instead of waiting for access to crucial resources. In addition, a release automation tool can help collapse development cycle times from days to minutes, enabling IT teams to spend more time improving the functionality, quality and security of their applications – and less manually promoting them from stage to stage.

Building Security into Policies

It used to be that every element of application development took place between an organization’s four walls, but with the rise of cloud and software-as-a-service (SaaS) technologies, it’s not uncommon for different stages of the SDLC to occur on different infrastructures. So if the environments are always changing, how do we ensure security is consistently addressed? By building it into the policies that comprise our continuous validation methodologies.

Release automation enables development teams to create policy-driven infrastructure provisioning rules that automatically determine what application elements can and cannot be staged on specific infrastructure types. For example, a common policy would be to never let customer or database information move to a public cloud environment, where sensitive information could be lost or stolen.

Creating an Audit Trail through Development

To this point we’ve centered the conversation mostly on security, but being able to maintain – and prove – compliance throughout the SDLC is an equally important challenge that IT development and operations teams must solve.

So when we think about compliance, we’re really asking questions like “What application moved from this stage to that stage?”, “Who released the application into production?” and “If there was a rollback, what was the cause and who rolled it back?” In other words, we’re talking about audit trails and logging all activities within the SDLC – something that can be difficult when numerous manual steps are involved. However, a release automation tool will capture all of this data as a matter of course as it automates release deployments through orchestration and promotion of applications from development through production. This means you’ll always be able to answer those who, what, where and when questions that pop up during audits.

Eliminating Vulnerabilities and Getting Back to the “Good Stuff”

I’ll admit that security and compliance are not the most exciting topics in DevOps. If application development were a meal, they’d be the pile of lima beans you have to eat before you get to the dessert that is innovative feature development. The good news is, service virtualization and release automation tools can help you speed and simplify the process of building security and compliance into the SDLC, which ensures your applications will hit the market without vulnerabilities – and lets you get back to the fun stuff.

July 7, 2014