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’.
DeMarco isn’t recommending specific methodologies like Agile, but this is a pretty good business oriented description of Continuous Delivery without continuous (production) deployment.
I’ve spoken to a lot of people about Continuous Delivery/Deployment over the years and a lot of the time i hear that the amount of time that it takes to implement it into a project is a cost their managers are simply not willing to allow them to incur. This is ludicrous.
In this follow-up post, we’ll explore some advanced options you can introduce once you’ve implemented the basic polling system. This post will show you how to configure Jenkins to automatically track versioned files using ‘file fingerprinting.’
Yeah, I know Monitoring Sucks, but it can be pretty neat as well. It’s a hard problem, so there are all kinds of interesting approaches to it. A new one I came across recently was the Assimilation Monitoring Project.
The documentation for Puppet on PuppetLabs is great, but it's a bit thick and similar to reading a book. I wanted something short to get me started with the fundamentals
It’s been a while since I posted about why devops makes sense in a job title and a few weeks and a few discussions later I have a some thoughts that you might find useful if you decide to go down the same path.
For about 2 months I was sitting with a dev team while we worked through how to build a new service which will be continuously deployed. I wanted to share my experiences here because I’ve read both positive and negative opinions about doing this and I’m not sure there’s a single right answer.
A common pattern in software development teams is to have a person who owns the build system. While it’s normal for some team members to have a deeper understanding of these things than others, it’s not a good idea for the knowledge and responsibility for the build to become overly concentrated in one person.
Interesting developments are now happening around how you model your system, how you percieve configuration, and whether you correlate the state of an infrastructure with its configuration.
I’ve recently decided to take the plunge and move from Apache and Mod_WSGI to Nginx and FastCGI – I was amazed at how simple it was! To get Edison up and running under Nginx as a fast-cgi Deamon, you just need to follow these steps...
Campfire is a really sexy HTTP based chat system provided by 37 signals. I've found a clone-type application written by @maccman on Github, called Holla. I'm gonna have a go at installing it on Ubuntu 10.04.
Here’s a bunch of upcoming talks, courses, conferences, things and stuff, which I reckon might be worth checking out.
Scp is slow, that’s a known fact. Known and so annoying that someone tried to fix it by producing the hpn-ssh patch.