Recently I got to know about RancherOS, which is an OS that provides pretty much only Docker host environment so that you can launch Docker containers.

My test environment is Mac OS Sierra with VMWare Fusion 8.5. What I did was as follows:

  1. Download ISO file for RancherOS
  2. Launch ISO via VMWare Fusion with 1GB ram and 10GB disk space (That’s normally what I use for linux distribution guest environment)
  3. Once I was on RancherOS terminal, I created cloud-config.yml file with ssh publick key in it. (Refer to the instruction)
  4. I made a note of IP address for the step #5
  5. After installing to the disk, I chose to reboot. From Mac terminal, I ssh’ed to the IP address of the RancherOS guest after RancherOS guest became available.

Pretty straightforward to install RancherOS on my mac.

RancherOS provides its own command line tool called ‘ros’ and this is the tool to configure the system, docker, etc.

Sync up Docker container time with Host’s

I’ve had some issues with my application’s user session being expired as soon as it got created. After further investigation, it was due to the fact that docker container’s time was far behind the current PDT(which is where I am and a default timezone for all my servers).

Easiest solution was to mount these two files from host to any containers:

After the two lines of docker volume, viola. Time synced between host and container.

Bye bye data-only container! Hello named volume!

Persistent data practice that I’ve been using with Docker has been the host volume although I knew that data-only container pattern existed.

So this time around, I was going to start utilizing data-only container pattern for some of db containers. However, I got to know that after docker version 1.9.0.

For example with data-only container pattern, we would have a docker-compose file like this:

However, a better approach would be:

New way of web application deployment: “Bakery” process

I have been quite interested in continuous deployment and working on ‘bakery’ process using OpenStack (which is another cloud environment comparable to AWS).

A traditional way of deployment is normally:

  • pull source code from source management on production env
  • create a tar file and then scp it & remote execute a script to untar
  • create a debian or rpm package, and then remote install it

They are ok ways, but main issue with them seems to be ability to keep multiple environment consistent and slow deployment processes.

Continue reading

vmware fusion and shared directory on a host machine

I’m using vmware fusion to create many development environments so that I have completely isolated ubuntu for client A, windows 2008 server R2 for client B, centos for client C, and so on.

Actually it was several months ago, but I was bothered to find a solution to this weird bug couple days.

On vm ubuntu, every time I use *composer* to update PHP project dependencies I end up with php parse error. They look something like this:

  • PHP Parse error: syntax error, unexpected ‘)’ in …
  • PHP Parse error: syntax error, unexpected ‘F’ in …
  • PHP Parse error: syntax error, unexpected $end
  • and so on…

BTW the temporary solution was to open a file, save, and then quit vim.

To fix the issue better than the temporary solution was:

  1. sudo vmware-uninstall-tools.pl (on the vm ubuntu)
  2. sudo apt-get install open-vm-tools

Since then I have not had the same issue before. Some reported that the solution that I took steps stopped working for them, but it wasn’t the case for me.

laravel’s database migration and seed

I have not used laravel 4’s migration and seed features much until couple days ago.
Oh boy, it’s a really sexy tool.

It does not matter whether you are in a team or you are all alone doing everything. It’s a feature that every single develop must use if integrating with a database!

Theoretically if you are a disciplined developer and use those features, confidence level of your database changes when deploying will be very high. I promise!

You will end up needing these if you decide to go with it:

*migration* file should be used for any changes that affect db schemas.
*seeding* file should be used to pre-populate data into db.

I thought it’d be beneficial to add some sample codes.

To create migration file, run this at Laravel’s app directory:

The above command line creates a file something like:

And its content looks something like this:

As you can take a guess, up method is where you change db schema. down method is where you rollback the change.

So let's say I want to add column "username" to "users" table.

(If you want to know more about available methods to manipulate db schema, click here.)

Now you want to run against your db? Then don't look further. Just run this:

After you run the command line, Laravel adds that particular code to migrations db table and that's how it keeps track of history.

Now you realize that you made a mistake and want to rollback your last change, run this:

I'll add seeding sample to the blog post later...

Why I am going full JavaScript

Recently I claimed that I would go full FE. Since I’ve been working on couple projects utilizing Backbone/Marionette, I realized that it’s about time for me to go full JavaScript even for BE using nodejs.

To be honest, I did not use nodejs much except running nodejs via forever and some hello world type apps. However, I’m planning to use javascript for everything as much as possible. Reasons are:

  • Community seems to be there to support you
  • One scripting language for FE/BE
  • Data transport over HTTP is done using JSON mostly
  • Many 3rd party Rest APIs support JSON
  • Performance got much much better

So that means, I will dig up build process, deployment process, and CI for Javascript sooner or later, which I’m happy to investigate.