This is a quick how-to post for Opsview users who have a need to monitor MarkLogic.
If you use Puppet in the client-server mode to configure your production environment then you might want to be able to copy & paste from the prod configuration into the Vagrant’s standalone puppet‘s configuration to test stuff.
Tools are important, people and relationships are importanter (new word), you should automate everything, take little steps instead of big ones, stick to the principles of continuous delivery. Here's my recent little case study on a client that wanted to implement CD...
This article is about measuring the Development cost of a Deployed Feature (DECODEF). This is probably the easiest figure to measure as, conceptually, is just the multiplication of man days times the average cost of your resources.
I work with “The Enterprise” everyday. Sadly, this has nothing to do with Star Trek – just big companies with lots of internal politics. As our friends champion our products internally,the political challenges are often tougher than the technical ones. If politics is going to be a barrier, it’s fair game to use political theory to fight back.
An indispensable IT ops measurement is FALT, (Feature Average Lead Time). What kind of measure is this and why is it important?
If you’re running collectd chances are you’ve struggled or are struggling with the web frontend. The one shipped with collectd has some limitations and most people tend to use 3rd party solutions. Graphite has its own storage system called whisper, so here are some things elated to that.
We often talk about tension caused competing bonus / success structures for development and operations teams in the build and release process. At Gartner IOM Cameron Haight framed this using the classic Prisoner’s Dilemma concept from game theory. I wanted to elaborate on that idea.
This was an interesting exercise, especially since I’d had caching and Puppet on the radar for quite some time now but I had not actually had a chance to use it or investigate it. The work paid off and will let our system scale up a whole lot more.
Establishing a devops platform in an enterprise environment is challenging because there are a bunch of groups who own different pieces of the puzzle, and they will generally have different ideas on how to move forward. But there’s a way to pull it all together into a coherent, integrated data and tools platform, and this post will explain how my colleagues and I are doing it.
I got my hands on the Definitive Guide to Drupal 7 that talks about Drupal use with Vagrant. I decided to take on this opportunity to automatically manage my own Drupal infrastructure.
In this post I will show how we are using Jenkins to pull a versioned binary out of Nexus and deploy to one of our remote test, staging or production Glassfish servers. By remote I mean that the Glassfish instance does not live on the same box as the Jenkins CI instance, but both machines are on the same network.
Continuous Delivery is all about setting up your development processes such that you can deliver into production much more frequently than is typical, perhaps with multiple releases per day. Here are 7 points I took away from a recent presentation...
I decided to see if RVM – Ruby Version Manager – would allow me to setup an isolated Ruby environment just for graylog2 and not disturb the other Ruby apps on the machine. I also wanted to setup an isolated instance of Passenger-standalone for graylog2 then configure apache to listen on port 80 and forwarding requests with mod_proxy.
Having a good Continuous Integration setup is the gift that keeps on giving, but what about your database? For most web applications these days, your database is a large part of your application – so why is versioning it such an uncommon thing?
“Availability is the most important thing…” I heard this recently and I cannot agree with it. It sounds good, until you think about all the things that become less important things when you say something like that.
A look at this week's news about Azure Linux support, multiple price drops by cloud providers, the Flame exploit, IPv6 growth, and what the browsers of the future will need to speed up the web.
For some, the task of automated deployments seems either too difficult, too time consuming to setup or is perceived as un-needed. I’m about to attempt to prove all of these things wrong, while at the same time allowing you to get back to doing what you do best: write code.
Previously I had looked at preflighting, with Hudson (And Jenkins) but forgot to mention a very important plugin that is essential if you want to convince your developer to preflight there work. The problem is that is the slave allotment/smallholder/farm is busy running other jobs then they are forced to wait before merging.
Previously I have written about using Hudson to perform pre-flights using branches on source control systems; but sometimes you just have a patch file that you want to run your tests against.
One thing we do is for every main hudson job we create a copy just to run the tests for a particular developer. It solves the "it runs on my machine" dilemma and frees up the developer to get on with other work.
Deploying in an automated fashion using Continuous Integration doesn’t happen instantly, and depending on the size of your application, your continuous integration deployment can get caught in a state of unknown/in-between if a user visits your application half way through deployment.
Having a good Continuous Integration setup can be one of the highlights of any developers daily grind. Regardless, it can be seen as almost pointless if your automated deployment setup still needs a physical person to upload the files to your server if it is offsite. Adding FTP/SFTP to your CI process is the solution to this.
A few months ago, I started to invest heavily in Chef to automate the roll out of our applications and the supporting infrastructure. So far, so good but it has not always been sunshine and puppy dogs. One of the major challenges is attempting to reuse cookbooks found on the community site, on GitHub or even within our own organization.
Make DevOps and NoOps a cornerstone of improving your software delivery; just don’t think NoOps PaaS entirely defines ‘What is a True, Complete PaaS’.