VGTech is a blog where the developers and devops of Norways most visited website share code and tricks of the trade… Read more



Are you brilliant? We're hiring. Read more
the

DevOps

category

Deploying apps in openshift

DevOps

After you’ve set up openshift with a node or two, deploying an application is as easy as it gets.

You can do lots of stuff in the broker console, but rhc is the way to go:

rhc is a rubygem installed like all others:

Show code
~$ gem install rhc

To set it up:

Show code
~$ rhc setup --server your-broker-01.example.com

(more…)


OpenVPN configuration files + Ubuntu’s network manager

DevOps

OpenVPN has feature that exports client configuration files. While it is definitely possible to run OpenVPN from the command line, I prefer to have a GUI that allows me to easily connect/disconnect from VPN. Ubuntu’s network manager and the .ovpn configuration files exported from OpenVPN does not play well together, however.

There is a workaround which involves cutting and pasting parts of the configuration file into separate files and adding some references to them in the configuration. After having done this a couple of times and helped other people with the same issue, I decided I’d write a simple tool to do the job instead. (more…)


Building your own PaaS

DevOps

In this series, I’ll go through installing, using and extending Openshift Origin, a Platform as a Service (PaaS), developed by RedHat. Check it out at https://github.com/openshift

What is Openshift?

In short, Openshift consists of two things: A broker, and a node. (or two brokers for redundancy and hundred nodes for scaling) Each can run on whatever; baremetal, vmware, ec2…..

The management is done on the brokers. It controls the automation and orchestration of the nodes.

The user created applications runs on the nodes. You can install broker and node on the same host, but I wouldn’t recommend it as You’ll get in trouble if your node gets too much traffic.

On the nodes the applications are separated into “gears”. These are SElinux hardened containers which are given a set of hardware resources(ram,cpu,disk) though linux cgroups.

(more…)


Varnish + requests with no Content-Length header

DevOps

HTTP 1.1 introduced the concept of chunked transfer encoding. This (among other things) enables us to send a request without knowing how large the content is going to be at the time we start the request.

An example usage would be where you generate content on-the-fly. You could potentially send chunks of a video-stream while you are recording or dynamically alter (compress, parse or similar) content from one source and incrementally send chunks to the server. (more…)


Varnish + HTTP Cache: An intro guide for web developers – Part 1

DevOps

Varnish, the web application accelerator:

varnish

Varnish development was initiated as a project within VG as a direct response to increasing demand hitting our servers hard. Existing caching systems were simply not fast or flexible enough to deal with VGs needs; and so Varnish was born with it’s first official release in 2006.

Varnish is now developed and maintained under a separate company (https://www.varnish-cache.org). It is open source (two-clause BSD license) and used among many large web applications including VG.
(more…)


How to make Ubuntu play nice with VMware

DevOps

ubuntuvmware

Here at VG a large amount of our services are deployed on virtualized servers in our VMware cluster. A majority of these servers are running CentOS, but from time to time there is a need for other distributions, like Ubuntu.

In this short write up we will go through a couple of things we find necessary to do to bring Ubuntu up to speed in a VMware environment. (more…)


Avoid Dependency on 3rd Party Sources With Composer

DevOps

Composer is the defacto standard dependency manager for PHP out there, also here in VG. We use it for not only our internal packages, but for all external packages like ZF2, Symfony, PHPUnit, etc. For the most parts it has been a pleasant experience, but it creates a hard dependency towards external sources as we now require these sources to be available when updating/installing. (more…)


Logging the correct IP address using Apache 2.2.x

DevOps

Here at VG we have loadbalancers and proxies in front of most of our webservers.
This is key to being able to handle the big amounts of traffic we get.

One problem that arise when traffic is being terminated this way is that the backend webserver, namely Apache will get either the IP of the loadbalancer or the proxy as originating address.

This is of course not desirable since we cannot see the actual client IP in the logs, and thus we cannot make other rules based on client IP in Apache.
(more…)