Phoenix deployment pain (and win)

I’ve posted previously on phoenix deployment, and thought I’d share an incident that happened that was resolved more easily because it was caught early.

Got a ping that the site was down, so looked into it.

Tried rebuilding the site using ShutIt and discovered quickly that apt-gets were failing.

So what changed?

I checked the network (fine), and then tried to repro on a simple ubuntu:12.10 image. Same there. I did the same on a completely different network. Tried hitting the apt urls directly – white screen.

A quick “ask around” later and I figure out that support for these ubuntu repos had been withdrawn.

So then I could work on an upgrade relatively quickly, and I had yesterday’s container to compare differences. In the meantime apache’s default security settings had changed, so that was quite painful.

But not as painful as it could have been, thanks to PD.

Advertisements

Phoenix Deployment with Docker and ShutIt

I wrote a website in my spare time (themortgagemeter.com) a few years ago for a family member’s business tracking mortgage rates over time in real time.

As an experiment I wrote it in such a way that the entire database would be backed up to BitBucket daily (as well as the running code on the live box). This allowed me to easily pull the repo, and dev straight off master wherever I was developing. It was well worth the investment; much time was saved in easy dev environment creation.

When Docker came along, I thought this would be an ideal opportunity to encapsulate the entire site in Docker to further this efficiency. Since there was configuration and interactions to manage, I used ShutIt to store the configuration and build steps.

Once it was containerized (or Shut), it was a short step to implement phoenix deployment.

Phoenix deployment is the principle of rebuilding rather than upgrading. Fortunately ShutIt made it easy to implement this.

Here is the script:

$ cat phoenix.sh 
/space/git/shutit/shutit build --shutit_module_path /space/git/shutit/library --image_tag stackbrew/ubuntu:raring
docker.io tag $(sudo docker commit $(sudo docker ps -a | grep -v themortgagemeter | grep raring | awk '{print $1}')) themortgagemeter
docker.io rm -f themortgagemeter
docker.io run -t -d -h themortgagemeter --name themortgagemeter -p 80:80 themortgagemeter

So now I have the peace of mind of knowing that whatever is running there now was built from scratch today.

With some simple tests (part of the ShutIt build lifecycle) and external monitoring (using Uptime Robot) I can be sure it will not suffer from bit-rot.

Docker, ShutIt and the Perfect 2048 Game (3 – Brute Force Escapes)

Docker, ShutIt and the Perfect 2048 Game (3 – Brute Force Escapes)

 

Now that I’m getting near the end of the highest tile on 2048, the air is getting thin.

I often get into a state like this:

Image

where I need a four – not a two – to drop in on the top.

Since fours are less frequent than twos, I have to start up, try, quit, and repeat multiple times, which gets quite tedious.

So I automated it using visgrep.

visgrep is a seemingly obscure tool (part of the xautomation package on ubuntu) to search for images within other images. I won’t go into its use here (it’s _not_ user-friendly and in-depth documentation is perhaps kept by monks somewhere), but there is a man page.

I’ve used it in the commented-out sections here:

https://github.com/ianmiell/shutit/blob/master/library/win2048/resources/start_win2048.sh

To use it, uncomment the lines, and put the appropriate key code in, save the container and run it as below:

host_prompt$ while [ 1 ]; do sudo docker run -t -i -p 5901:5901 -p 6080:6080 -e HOME=/root imiell/2048_left /root/start_vnc.sh; sleep 5; done

New 'b80055fbbeff:1 ()' desktop is b80055fbbeff:1

Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/b80055fbbeff:1.log

Did you expose ports 5901 and 6080?
If so, then vnclient localhost:1 should work.
18874476
307,129 0
307,130 0
306,131 0
307,131 0
308,131 0
307,132 0
307,133 0
0
FAIL
[about output loops n times]

New '3fd43021ea4a:1 ()' desktop is 3fd43021ea4a:1

Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/3fd43021ea4a:1.log

Did you expose ports 5901 and 6080?
If so, then vnclient localhost:1 should work.
16777324
0
OK
container_prompt$

So when I see an “OK” and a prompt within the container I know I can vnc in and continue playing.

The time saved by doing this is significant.

I’m not really a game player, but I imagine this principle could be applied to a lot of games. Also, the process could be made much more slick, as this is still very much by-hand.

 

Docker, ShutIt, and The Perfect 2048 Game

 Docker, ShutIt, and The Perfect 2048 Game

I cured my 2048 addiction by (almost) completing it. Obviously I didn’t get this far without cheating, but I did play every move.

2048

 

I could have hacked the Javascript or the client-side db, but I actually wanted to see if it was possible to complete the game. So I used the old-fashioned “save game” functionality to keep state.

Here’s how it’s done, and it should work on pretty much anything.

1) Get Docker

See above link to: https://www.docker.io/gettingstarted/#1

2) Get ShutIt

$ git clone https://github.com/ianmiell/shutit.git

ShutIt is used to build docker containers in a lego-like fashion. It’s designed to allow you to string together complex builds of containers in a linear way while maintaining control and reproducibility.

We use it here to build a container with a vnc environment.

Documentation here

3) Build win2048 Image

$ cd shutit

$ # Do some bogus password setup
$ cat > library/win2048/configs/$(hostname)_$(whoami).cnf << END
[container]
password:acontainerpassword
[host]
username:ausername
password:apassword
END
$ # secure config files first
$ find . | grep cnf | xargs chmod 0600

$ cd library/win2048

$ python ../../shutit_main.py --shutit_module_path ../vnc

Wait for it to finish:

[...]
Building: shutit.tk.vnc.vnc with run order: 0.322000000000000008437694987151189707219600677490234375
Completed module: shutit.tk.vnc.vnc
Building: shutit.tk.win2048.win2048 with run order: 0.326000000000000011990408665951690636575222015380859375
Completed module: shutit.tk.win2048.win2048
# BUILD REPORT FOR BUILD END lp01728_imiell_1399663295.26
################################################################################

4) Commit and Tag the Container

Pay attention to the bold text – it will need to be changed for your run

$ sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4335e86a64ca ubuntu:12.04 /bin/bash 9 minutes ago Exit 0 sick_franklin
 
$ sudo docker commit 4335e86a64ca
e3a7a9926654c8c28c1252407a4b7ee272cb7fb6ad5640ad1f54e1cacf402bb2

$ sudo docker tag e3a7a9926654c8c28c1252407a4b7ee272cb7fb6ad5640ad1f54e1cacf402bb2 yourusername/mywin2048

5) Run Up the Container

Pay attention to the bold text – it will need to be changed for your run

$ sudo docker run -t -i -p 5901:5901 -p 6080:6080 yourusername/mywin2048 /bin/bash
$ /root/start_win2048.sh

6) Play

(In another terminal)

$ vncviewer localhost:1

Password:

vncpass

7) Save Game

In another terminal:

sudo docker tag $(sudo docker commit $(sudo docker ps -a | grep -w "-p 5901:5901 -p 6080:6080" | grep -w Up | awk '{print $1}')) username/mywin2048

 

Can you play through to the end and get the perfect 2048 board?

2048closeup