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.

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

volumes:
  - /etc/timezone:/etc/timezone
  - /etc/localtime:/etc/localtime

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

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:

# version 1 docker-compose
db:
  image: "mysql:5.6.28"
  expose: 
    - "3306"
  volumes-from:
    - dbdataonly:rw
  ...
dbdataonly:
  image: "ubuntu:14.04"
  volume:
    - /var/lib/mysql

However, a better approach would be:

version: "2"
services:
  db:
    image: "mysql:5.6.28"
    expose:
      - "3306"
    volumes:
      - dbdataonly:/var/lib/mysql
    ...
volumes:
  dbdataonly:
    driver: local

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.

Often times, developers/ops find their application non-functioning after pushing to stage or production environment. Later they find some packages were missing. I’ve encountered such situations so many times in the past.

What improvements can be made to improve the consistency issue?

Well, virtual machines on openstack/AWS or even container image such as Docker can be created and then deployed instead to minimize human error as much as possible. With that notion, worst thing that can happen is some environment info is still development. However, every single package, application code, and config files are moving to one environment (dev) to another (stage or production). See? We are seeing the consistency here already.

What are cool things about having such system?

1. Consistency
2. Faster deployment
3. Rollback is super easy because entire os including application code and dependent packages are already embedded to the virtual machine. Just create a new instance using previous virtual machine image and then put it in use. BAM! You have an old version of application up and running

So what are steps to make that happen?

To be frank, it is not simple to implement a such system. The very foundation is a well established continuous integration. On top of that automated functional/integration/regression tests are required as well (technically, they are not. However, they will make things smooth in the long run).

At a high level, these are the steps:

1. New Code gets checked in
2. Triggers CI job : compilation, unit tests, and packaging
3. When everything looks good, a new virtual machine image (Openstack/AWS/Docker) with the latest application package on it gets created and called Bakery process.
4. A new instance gets spun up using the newly made virtual machine
5. functional/integration tests are done against the new instance
6. When tests are all green, the new image gets promoted as production ready and wait for developer’s final OK
7. Developer gives OK and the new instance gets spun up and goes under production load balancer starting to take live traffic
8. At that point, old instance and new instance are both up and running. New instance is expected be completely backward compatible
9. Developer kills old instance when the new instance does not cause any issues

In the next post, I will write about some details on step #1, #2, and #3.

UPDATE: Netflix tech blog posted the same thing pretty much today (Mar 9th, 2016) – http://techblog.netflix.com/2016/03/how-we-build-code-at-netflix.html

List is as follows:

• (Capri Tools C098 3lb Dead Blow Hammer, Orange PU)
• (Stanley 42-324 24-Inch I-Beam 180 Level)
• (Steel Grip Mallet 16 Oz Hardwood)
• (Safety Ear Muffs)
• (Fluorescent 135 Feet Line Reel)
• (MSA Safety Glasses)
• (Comfy Mask – Lawn & Garden, Woodworking, Dust, Drywall & Sanding)
• (Stanley 16-294 Mason’s Chisel)

Now California weeds took over my grass and it got already out of my hand. Facing the backyard challenging, I’ve set a resolution for 2016 although it’s already past the new year: Backyard Makeover!

Without further due, this is the current state of my backyard.

Started digging up.

cd path/to/project-b
git remote add project-a path/to/project-a
git fetch project-a
git merge project-a/master # or whichever branch you want to merge
git remote remove project-a

So that was to merge project-a into project-b.

One thing I need to note is that project-b and project-a have to be git-cloned already, so prerequisite for the above the order of execution was as follows:

cd path/to/project-b
git clone https://github.com/blahblah/project-b
cd path/to/project-a
git clone https://github.com/blahblah/project-b

Also, don’t forget to commit your changes after the merge.

I found this pro tip from this.

So I ended up with adding an alias to my .bash_profile file as follows:

## in .bash_profile
alias http="python -m SimpleHTTPServer"

## run it like this
http 8000

Note that port number below 1024 cannot be bound as a normal user. This is meant to simply run a http server for development purpose. Do not use it to run your web application.