Inside NGINX: How We Designed for Performance & Scale
The #! magic, details about the shebang/hash-bang mechanism on various Unix flavours
ClearOS – IT infrastructure Linux distribution.
I spent a large chunk of yesterday experimenting with Vagrant on my Fedora 21 laptop. I’ve used it before of course, but a friend asked for help with something I was planning to play with for a long time, so it unexpectedly lead me into a journey.
Let’s start simple. If you want the least possible amount of hassle with running Vagrant on Fedora, you should use it with Oracle VirtualBox provider (sometimes also called hypervisor). It works great! The only troubles with this approach is that VirtualBox relies on a kernel module (kmod-VirtualBox RPM), which has to match your current running kernel version to a digit. This kernel module is NOT part of the official Fedora repositories, and, instead, can be found in the RPM Fusion yum repository (rpmfusion-free-updates). This means that sometimes, when Fedora releases a kernel update, it might take a few days for the RPM Fusion repository to catch up with the kmod-VirtualBox updates. And this, of course, might result in your Vagrant setup being broken.
The easiest way to protect against that is to disable automatic kernel, kernel module and VirtualBox updates. To do so, add the following line to the [main] section of your /etc/yum.conf file, right after your VirtualBox/vagrant setup started to work:
exclude=kernel* kmod-* VirtualBox*
Now, if you forgot to do that a few times got pissed off with this situation (or don’t like Oracle for some reason), you might consider alternatives. Which are a few. Vagrant supports a variety of hypervisors. One of the common alternatives is to use libvirt, which is shipped with Fedora distribution.
Installing libvirt is simple (thanks to this blog post). Here’s pretty much all you have to do:
yum install libvirt libvirt-daemon libvirt-daemon-qemu virt-manager service libvirtd restart
The problem that you might realize now is that libvirt is not the most popular provider for boxes in the Vagrant world. Most people seem to prefer VirtualBox. But if your choices are satisfied, I’m glad for you. If they are not, however, there is a work around that you might go for – vagrant mutate plugin. This plugin converts vagrant boxes from one hypervisor to another.
In order to install this plugin on Fedora 21 you’ll need a few development tools first (this StackOverflow thread definitely helped with the weird g++ error):
yum install ruby-devel gcc-c++ make
Once you have those, install the vagrant plugin with your regular user (the one who will run vagrant VMs):
vagrant plugin install vagrant-mutate
Now you can mutate Vagrant boxes. Unfortunately, you might find that mutate plugin doesn’t like boxes with slash in their names (like chef/centos-6.5). The suggested workaround is to either use box names without slashes, or to provide mutate plugin with the box URLs, rather than names. The official boxes directory doesn’t give you URLs though, so you might be stack with random GitHub repositories or with an alternative directory, like Vagrantbox.es.
My adventures with this aren’t over yet. Feel free to send suggestions my way. From my side, here are a couple of other useful links on this subject:
- It looks like the upcoming Fedora 22 will handle things better.
- If you are using Vagrant boxes on Windows, you are probably familiar with file permission issues across synced folders.
- If you want to have several VMs with Vagrant, here are some handy configuration snippets for those who aren’t well versed in Ruby.
One last bit of advise from me is that until you are absolutely sure that your Vagrant setup works perfectly, stick to 32-bit box images. There’s nothing like ripping your hair out for three hours only to learn that your host hardware is 32-bit while you are trying to boot into a 64-bit operating system.
I nearly had a heart attack … it took me a couple of seconds to realize that this was a prank…
@mamchenkov Are you talking about GNU+Linux ?
— Richard Stallman (@rmsthebot) May 8, 2015
Well played, well played …
P.S.: For those of you who don’t know who Richard Stallman is – shame on you. :)
P.P.S.: Easy for you to spot the “bot” part here, but I saw on this on the mobile app, which was more insisting on the name rather than the handle.
I came across “Do Not Use Amazon Linux” opinion on Ex Ratione. I have to say that I mostly agree with it. When I initially started using Amazon Web Services, I assumed (due to time constraints mostly) that Amazon Linux was a close derivative of CentOs and I opted for that. For the majority of things that affect applications in my environment that holds true, however it’s not all as simple as it sounds.
There are in fact differences that have to be taken into account. Some of the configuration issues can be abstracted with the tools like Puppet (which I do use). But not all of it. I’ve been bitten by package names and version differences (hello PHP 5.3, 5.4, and 5.5; and MySQL and MariaDB) between Amazon AMI and CentOS distribution. It’s an absolute worst when trying to push an application from our testing and development environments into the client’s production environment. Especially when tight deadlines are involved.
One of the best reasons for CentOS is that developers can easily have their local environments (Vagrant anyone?) setup in an exactly the same way as test and production servers.
Linux Insides – a little bit about a Linux kernel
Today at Build, Microsoft unveiled its first version of Visual Studio for Mac and Linux.
The new tool, called Visual Studio Code, makes it easy to develop .NET code along with many other programming languages on Linux based systems.
It’s monumental for Microsoft as it marks the first time the company has ever made Visual Studio cross-platform, truly embracing those that it’s previously feuded with.
I’ve been using Puppet here and there for about a year now. In the last six month, I went rather heavy, and managed to accumulate quite a bit of modules, configs, hosts, etc. Refactoring some of the code, and trying out new ideas, I’m reading through the Beginner’s Guide to Modules to help me with the best practices. A couple of bits from there, I think, are worth quoting:
(Tip: If you describe the function of your module and you find yourself using the word ‘and’, it’s time to split the module at the ‘and’.)
This above is useful to people like me, who got comfortable throwing bits and pieces into modules, but don’t quite know yet where is that thin line for the module separation. The above tip makes that crystal clear. So, for example, “my module installs and configures something” no becomes two modules, where one “installs something” and another “configures something”.
It is standard practice for Puppet users to have upwards of 200 modules in their environment.
With this I know that my current setup is rather small and simplistic. It’s not the numbers I am after, of course. But, again, it’s difficult to say if I am doing too much of it, or not enough; if the system has been built to scale to the level where I am. It turns out, I have a long way to go. A quick check shows that I’m at 127 modules in my current setup. And that one is used for configuring pretty much everything – base installs, web / db / dev servers, desktops, etc.
Some of it will get expanded as I am replacing quite a bit of my own modules with third-party ones. Interestingly enough, I wasn’t comfortable using other people’s code in the beginning and wanted things to be precisely my way (there were some time constraints). It worked well, for a time. But not a lot of it can be thrown away and replaced with other people’s code. More features and less maintenance for the win!