Cloud, DevOps, General, Technology

How To Move your large VirtualBox VM disk created by Docker


So you’ve been using Docker Tool Box (DTB) on Windows and the ‘default’ docker host created by docker-machine is growing alarmingly large on your limited C: drive.

The super large disk.vmdk file for the “default” VM created by DTB is usually located at C:\Users\[username]\.docker\machine\machines\default

Now you want to move the existing disk.vmdk file to your much larger D: drive without having to recreate a docker machine/host from scratch and pulling all images on to it again.

The important thing to note here is that the vmdisk is an implementation detail of VirtualBox (VBox) not Docker. docker-machine just uses VBox as a provider to create a Docker host.

Therefore if you need to move the VM disk file to another location you should change VBox configuration for the VM instead of changing any Docker machine configurations (or using any docker commands)

So here  are the steps you need to follow.

1. Stop the running docker machine (i.e. VBox VM) like so:

                   docker-machine stop  

Note: This will effectively power off the VBox VM, named ‘default’. You can check this by opening the VBox GUI.

vbox_default_off

2. Copy the disk.vmdk file from C:\Users\[username]\.docker\machine\machines\default to a suitable folder in your bigger D: drive. I created D:\docker-machines\default for this.

Now the interesting part 🙂 We need to tell VBox about the new location of the disk.vmdk file.

3. The default.vbox file located at C:\Users\[username]\.docker\machine\machines\default\default  specifies the path to the vmdk file. This vbox file is an XML file, so just open it up in any editor and set the Machine/MediaRegistry/HardDisks/HardDisk/location attribute to the new location on your D: drive.

docker_vm_move

Note: Don’t worry about the “DO NOT EDIT THIS FILE..” statement on top since you have already stopped the VM, the file will not be overwritten. And I found this method easier than using the GUI 🙂

4. Now power up the docker machine using:

                docker-machine start

If the ‘default’ machine start without any problem then you are good to go!

Now check if all your images are still available using:

docker images

5.  You can verify that the vmdk file on D: is being used by firing up VBox and selecting the “default” VM and clicking on Settings/Storage/disk.vmdk as shown below.

docker_new_vmdk

6. Now you are done! Just go ahead and delete the huge disk.vmdk from your C: drive located at  C:\Users\[username]\.docker\machine\machines\default

Advertisements
Cloud

Quick way to check threats on your webserver


Since the most common language used to build sites on the Internet is PHP a majority of attacks to a web server will be looking for “PHPy” stuff.

If you build a non-PHP site you can have a quick look at the “PHP attacks” on your web server using a simple Linux cat+grep command on your web server’s access log.

Here’s an example for nginx:

sudo cat /var/log/nginx/access.log | grep php

php_threats

Looking at the output it’s apparent that some sort of automated script is accessing a number of well known vulnerabilities in PHP based web frameworks. The “myadmin” threat is probably trying to take over the MySQL database of the site. Of course in this example all of these are 404s which means the attacker did not get through.

If you want something more comprehensive than simple Linux commands try GoAccess. It’s a neat little utility which parses your web server’s log and gives a cool terminal based Dashboard.

But the important thing is to regularly “keep an eye” on your web server’s access logs for potential threats that may take your site down.

Cloud, DevOps, MySQL

Connecting to MySQL running inside Vagrant


Vagrant is pretty neat! It helps dev-teams or even stand-alone developers to easily setup their machines by making their development environments “configurable, reproducible and portable“. All the details about your dev setup is specified in a file called Vagrantfile.

This is really handy if you use a Windows/Mac machine for your IDE but want to have a Linux based “runtime-box” consistent with your Cloud/VPS environment to deploy and test your app.

But this post is not about how to setup and use Vagrant itself, the Vagrant docs does a superb job to help you get started. This post is rather about a simple method that you can use to connect to a MySQL server running inside your Vagrant box.

Let’s say you are running a MySQL server on the Guest (e.g. Ubuntu) inside your Vagrant box, how do you connect to it from your Host (e.g. Windows)?

The first thing that came to my mind is the port forwarding functionality provided by Vagrant it self, where you can perhaps say 3366 (Win/Host) -> 3306 (Ubuntu/guest)

But there is a much easier way to do this since Vagrant by default allows the host to connect to the guest through SSH you can use MySQL workbench installed on your host (Windows/Mac machine) to connect to MySQL running inside you Vagrant/Ubuntu box as shown below.

mysql_ssh

Note: The connection only uses the default SSH port forwarding (2222 -> 22) and MySQL port remains the same.

Cloud, Mobile

The PC will die long live the Mobile!


With all the predictions about the future of Mobile and the current proliferation of Smartphones, Tablets and other devices to come its mind blowing that software developers as well as software vendors are still not fully committed to a mobile first strategy when developing software be it for the consumer or the enterprise.

As a developer it’s really important to sharpen your saw with technologies pertaining to the Mobile ecosystem. This does not just involve the mobile device side of things such as Android, iOS (Objective C), HTML5/CSS3/JavaScript, PhoneGap etc., but also the server-side of things such as REST APIs, mBaaS, Cloud etc.

This is a really interesting presentation on why a “Mobile First Strategy” should be on the minds of every software house/developer.

Cloud

EC2 instance suddenly missing in AWS console?


I’ve been playing around with the free tier AWS EC2 instance (t1.micro running Ubuntu 12.04) for some time now. I keep the instance running 24×7, since according to this by Amazon I am less likely to wander out of the free tier and get charged. Remember you have to provide your credit card details to be eligible for the “new customer – free tier” plan available for 1 year.

Amazon provides a nice console to manage (start, stop, terminate,configure) EC2 instances. Since my EC2 instance is running all the time , I’m used to seeing the green circle  along with the instance details when I login to the AWS console (as shown below).

aws_ec2_running

But today when I logged in to the console it was totally empty i.e. no instance running. Instead of the screen shown above I got this screen telling me to Launch a new instance. 

aws_ec2_launch_msg

Does this mean that I lost all the configuration done in my previous instance? Since I had deployed a small demo web app to the instance previously I tried accessing it from my browser, to my delight (and confusion) it was up and running.  But then where on earth is my ec2 instance in my console???

The answer lies in the way Amazon provisions its EC2 instances from different regions such as US East, US West, South America, Asia etc. The EC2 Management console displays instances based on regions (bad design perhaps?) and somehow my region setting in the console had changed to something else.

Fortunately the region can be easily changed in the console using the drop down menu in the header bar. When I changed it to US West (Oregon), Voila!!! my ‘freebie’ t1.micro instance reappeared in all its glory :).

missing_ec2_instance

So don’t panic and create new instances if your EC2 instance goes missing in the AWS console, make sure you have selected the correct region. 🙂