To infinity, and beyond!

Editing a Polymer web component’s CSS from React

2019-05-07T01:00:00+00:00

Just for some context, I recently got (temporarily) involved in a new React project that uses a third-party lib built on top of Polymer.

Since the whole rest of the project is in React we built some “adapters” for the web components, which makes them easier to use and encapsulates anything “weird” we might want to do:

// the component's .js is imported directly
// from index.html, since the lib is distributed
// in a single .js file
class CustomPane extends Component {
  render() {
    return (
      <custom-pane
       { ...this.props }
      >
        { this.props.children }
      </custom-pane>
    );
  }
}

Don’t get me wrong, web components are awesome. The use os Shadow DOM to encapsulate the implementation is great. This pane, however, has a nasty surprise: its width is hardcoded (in px)… in a style element, inside the Shadow DOM. Meaning you can’t override it with a global style - in web components styles are scoped and, even though they inherit from the parent, the child’s style will always override it if set.

ProTip: Polymer components allow theming with CSS properties. If you intend for others to use your components, please expose some properties to make their lifes easier.

Of course, in our case that wasn’t an option - we can’t modify the source of the lib. So what now? Well, lucky us, Polymer (by default) creates an open shadow root, so you can just… append some CSS, and overwrite what’s there!

We start by creating a Ref, so the actual DOM element is available in our React component:

class CustomPane extends Component {
+  constructor(props) {
+    super(props);
+    this.element = React.createRef();
+  }

  render() {
    return (
      <custom-pane
+      ref={this.element}
       { ...this.props }
      >
        { this.props.children }
      </custom-pane>
    );
  }
}

We need to access the element after it has been created on the DOM, so we use the proper lifecycle method to do it. We also want to add a new style node to overwrite the class that’s being used:

class CustomPane extends Component {
  constructor(props) {
    super(props);
    this.element = React.createRef();
  }

+ componentDidMount() {
+   const { style } = this.props;
+   const properWidth = style && style.width;
+   if (properWidth) {
+     const newStyle = document.createElement('style');
+     newStyle.innerHTML = `.pane-wrapper { width: ${properWidth} !important; }`;
+     const host = this.element.current;
+     host.shadowRoot.appendChild(newStyle);
+   }
+ }

  render() {
    return (
      <custom-pane
       ref={this.element}
       { ...this.props }
      >
        { this.props.children }
      </custom-pane>
    );
  }
}

We get the wanted width from our props, append it to the Shadow DOM… so far, so good, right? But there’s a catch: At this moment, we are still inside React’s lifecycle. The HTMLElement “custom-pane” has been created on the DOM, sure, but it still hasn’t been actually rendered by Polymer - so it has no shadow root for us to use. For that to happen, we have to wait until everything is done on this tick and append our style on the next one:

class CustomPane extends Component {
  constructor(props) {
    super(props);
    this.element = React.createRef();
  }

  componentDidMount() {
    const { style } = this.props;
    const properWidth = style && style.width;
    if (properWidth) {
+     setTimeout(() => {
        const newStyle = document.createElement('style');
        newStyle.innerHTML = `.pane-wrapper { width: ${properWidth} !important; }`;
        const host = this.element.current;
        host.shadowRoot.appendChild(newStyle);
+     }, 0);  
    }
  }

  render() {
    return (
      <custom-pane
       ref={this.element}
       { ...this.props }
      >
        { this.props.children }
      </custom-pane>
    );
  }
}

And that’s it, we’re finally done! We’ve now successfully customized a Polymer web component with hardcoded CSS properties! (:

This is what us brazilians usually call a “gambiarra”. If you are writing web components, please don’t force people to do it… allow customization points where appropriate!

Docker Desktop troubles on Windows 10

2019-02-27T01:00:00+00:00

A funny (and annoying) error just happened today: a docker setup that was working yesterday simply stopped working today with a weird message:

Cannot start service backend: OCI runtime create failed: container_linux.go:296: starting container process caused "exec: \"./wait-for-it.sh\": stat ./wait-for-it.sh: no such file or directory": unknown

There’s really nothing special about it: a simple python:alpine image, started by docker-compose, with volumes bind mapped to a directory on Windows 10. When running docker run -it --rm backend /bin/sh you could see the ./wait-for-it.sh file there, and run it. git status gave away nothing, and it was working for everyone else.

And yet, when removing the bind mount volume, everything started working again.

After a bit of googling you end up finding docker/compose#4039, and one of the comments lost in history in there mentions changing your password (on Windows) may end up with weird consequences. I hadn’t changed it, but still, it was worth a try…

The button you have to click is "Shared Drives" -> "Reset credentials"

And yeah, resetting the credentials deshares the drives, asks for your admin password, and shares it again - which makes everything start working again.

After you know this, it’s actually quite easy to find the official documentation that explains it better. Until then, I hope googling the error message brings you here and helps you out a bit (:

Improve your selectors with dependency injection

2017-09-06T01:00:00+00:00

If you’ve ever had to deal with derived data in redux, you know those can be kind of a pain once your state is normalized - so you start using reselect.

This leads to some code like this (example adapted from the official reselect docs):

// in your selectors...

import { createSelector } from 'reselect';

const shopItemsSelector = state => state.shop.items;
const taxPercentSelector = state => state.shop.taxPercent;

const subtotalSelector = createSelector(
  shopItemsSelector,
  items => items.reduce((acc, item) => acc + item.value, 0)
)

const makeTaxSelector = () => createSelector(
  [subtotalSelector, taxPercentSelector],
  (subtotal, taxPercent) => subtotal * (taxPercent / 100),
);

// and in your container...

const makeMapStateToProps = () => {
  const taxSelector = makeTaxSelector()
  const mapStateToProps = (state, props) => ({
    tax: taxSelector(state, props),
  });
  return mapStateToProps;
}

The problem there is that once you call taxSelector, you hava an implicit dependency on how your state is structured - over time, specially if you start creating generic reducers/selectors, this causes some problems both when documenting and when trying to reuse the code.

For instance, a coworker recently realized we were duplicating selector code because in some components our taxPercent equivalent was indeed in the state, but in others it was in a prop - imagine for instance you wanted to calculate both domestic and international tax rates. Might also be a good use for re-reselect, buts a whole different topic.

So we made a somewhat subtle change in how we write our memoized selectors, and started injecting selector dependencies (but keeping the state as a default):

const shopItemsFromState = state => state.shop.items;
const taxPercentFromState = state => state.shop.taxPercent;

const subtotalFromState = createSelector(
  shopItemsFromState,
  items => items.reduce((acc, item) => acc + item.value, 0)
)

const makeTaxSelector = 
  (subtotalSelector = subtotalFromState,
   taxPercentSelector = taxPercentSelector) => createSelector(
    [subtotalSelector, taxPercentSelector],
    (subtotal, taxPercent) => subtotal * (taxPercent / 100),
);

We also created some “utility” selectors to ease the use on the containers:

const constSelector = value => () => value;
const propSelector = prop => (state, props) => props[prop];

So when we are testing a selector, we now do:

  const taxSelector = makeTaxSelector(constSelector(42), constSelector(10));
  expect(taxSelector()).to.equal(4.2);

Now our selector unit tests don’t break when we modify state structure, and we get to reuse code in more containers that do the same thing in multiple places!

Migrating to a static blog with Jekyll

2017-05-30T21:01:00+00:00

I’m the first to point out that this blog has been dead for ages, but it (somewhat surprisingly) still gets some decent number of page views - which is why I was slightly annoyed when randomly checking the “old” blog (with Ghost) and figuring out it was not properly working.

Side note: Yes, there was a free uptime check set up, but Ghost would actually render the page and just fail to serve the CSS - making the site unusable, but still “online”. The Ghost container was set up to automatically update with new images from Docker Hub, keeping data in a separate volume. Since I wasn’t keeping a close eye on it I have no idea on which version this actually happened, but one of my “newer” posts also vanished in the process (since restored from an older backup).

Since I had some time to spare, I took the opportunity to have some fun and migrate the whole thing to a static site - no more having to worry about Ghost, about updates, nginx configuration, etc, etc… now, you do lose some UX by doing that (I’m now writing everything in markdown text files in Sublime and then git commiting it to a respository, so no “edit” button for a typo), but there are also quite a lot of advantages:

Everything is faster and more reliable

Depending on your host, of course, but no more databases to query. No more databases at all! No worries if you have only two users of a gazilion, you’re just using bandwidth and not CPU resources, memory…

CDNs also work better. I’m still using Cloudflare because of their DNS flattening (I like naked domains, but Netlify does not), even though Netlify also has a CDN + SSL in their free plan.

Because everything is static and cached, you don’t have to worry so much if your database goes down or if your CMS has an issue.

Free hosting

GitHub Pages is nice, but it forces all your files to be open source. I’ve been using Netlify, which also has a free plan.

Continuous deployments

Netlify also has this cool feature where you link a git repository and they build and serve it (in my case, I commit the jekyll config/layout/markdown post files and it automatically builds the complete thing). Using webhooks, every new commit turns into a new version of your site being built and deployed automatically.

Pull requests from your main branch can also be built and are automatically served in a new subdomain for a preview. Nice!

Comments

I was already using disqus, meaning not having to deal with managing posts. Just edited the template to include them, migrated existing comments to the new URL scheme, and voilà.

I still love DigitalOcean and their cheap servers, but from now on I’ll not be using those to host simple stuff anymore (:

From zero to Docker: Continuous Deployment with wercker and Docker Hub

2016-04-16T21:00:00+00:00

So you’ve read about this “continuous delivery” or “continuous deployment” thing - great! But how do you integrate that in your workflow in practice? If you are using Docker, you are just a few steps away from having your code automatically tested, built and deployed after each commit on Git.

First things first: Continuous Deployment assumes you are doing your homework with Unit Tests, and that (most) things that can break will be caught by those. Deep in JUnit/mocha/whatever technical debt? You can always auto-deploy to a staging area just to see if things keep working.

Docker’s latest acquisition of Tutum is a big step in having it all in one integrated environment, but since they don’t (yet) support builds from Bitbucket we’ll be using wercker to build our images.

After creating your account at wercker you’ll need to link your GitHub/BitBucket account and select the repository to build from - that will add a deploy key to your repository, if it is private.

Wercker uses its own version of a Dockerfile they call wercker.yml - In there you select a base docker image such as node:5 and add a few build steps such as npm install.

box: node:5
build:
  steps:
    - npm-install
    - npm-test

As you can see, I’ve also added a npm test step that will run the all the test suite - if it fails the build process will stop, the image will not be deployed and you’ll be warned by email.

You can also add your deployment info. In my case I’ve used the default Docker Registry:

deploy:
  steps:
    - internal/docker-push:
      username: $USERNAME
      password: $PASSWORD
      repository: marcelofs/nodejs-web-boilerplate
      ports: "3000"
      working-dir: $WERCKER_ROOT/backend/
      cmd: npm start

I’m sure there’s a good reason they don’t use the Dockerfile we already maintain, but in the end you just repeat your build code.

You can now go to the settings in the web interface and add a “target” to your deploy - the idea is that you could have multiple deploy targets with a different configuration for each one. It’s a bit unintuitive - you have to define it on your .yml and define it again on the web interface, which allows you to set the environment variables used above and set it as “auto deploy successful” builds.

This means that every time you commit to the repository wercker will download your code, build your environment, run your tests, create a Docker image, and deploy said image to Docker Registry. There are other workflows you can configure, but to be honest their documentation is a bit confusing and their examples didn’t look much better than the development workflow I use now.

wercker build

You’ll also get a bunch of other usefull stuff such as one of those “buttons” with your project’s build history and a column on BitBucket’s commit history telling you whether that commit passed or failed the build.

From there we’ll use Docker Cloud to deploy the built image to our servers. I usually use DigitalOcean’s droplets to test stuff like this, but there are a bunch of other providers available and you can use pretty much any Ubuntu node.

If you sign up using this link, you’ll get free $10 of server credit

After you’ve added your node to Docker Cloud’s web interface, just configure a new Stack and use the autoredeploy feature:

madruga:
  image: 'marcelofs/nodejs-web-boilerplate:latest'
  autoredeploy: true
  restart: always

And that’s it, Docker Hub will automatically get the built images and deploy them to your server! But I’ll say again: if you enable continuous deployment in production, you better make sure your unit tests are good (;

Oh, and if you configure bithound for your project you’ll get another fancy button with the quality of your code and some dependency analysis. They promised a free private project slot last year and the blog post has since been deleted, but one can hope…

Some useful Git tips

2015-11-16T21:00:00+00:00

Tools

Atlassian’s SourceTree is probably the best GUI for Git, but is only available for Windows/Mac. It integrates with gitflow but does not have a good built-in merge tool.

GitFlow

nvie/gitflow is a useful tool based on to implement a branching model as described in this famous article by Vincent Driessen (this tutorial also helps). The model uses clearly specified master/development/feature/release/hotfix branches that are automatically supported by the tool. For instance, you can:

Create a Release that will merge your current Development with Master and also Tag it
Create a Hotfix that will be based on Master and merged with Development when closed

gitflow

gitflow keeps a linear history of versions on the master branch. If there is the need to keep multiple versions at the same time (for instance fixing v0.1 after v0.5 has been released) this SO answer can provide some guidance. We’ve also had a good experience by not releasing the new versions, instead deciding to keep them on Development and manually tagging - this breaks the history, but allows us to keep working on v0.14 (deployed version with the client) while still keeping track of our sprints with tags.

Merge vs. Rebase

We should aim to lower the amount of useless git commits in our git history. For instance, in the below screenshot we have 23 commits but 10 merge commits:

too many merge commits!

This happened because people were working and commiting locally but not keeping their local repository in sync with the remote. When trying to push, someone else had already commited to the remote and that would cause an ancestor conflict; this would mean that when pulling a new automatic merge commit would be created (merging the remote and local branches).

To prevent that from happening:

Stash your changes, pull from the remote, stash pop to apply your changes on top of the latest version, commit, then push. See this article; or
Use a feature branch if you want to have multiple commits. It is useful to merge development>feature before merging feature>development to resolve conflicts, and we’ll have merge commits that “make sense”:

nice merges

On the terminal use git merge --no-ff --log (avoids fast-forward and adds all history messages to the merge commit); or
If you have already created your commits, when pulling use rebase instead of merge (on SourceTree it’s the last checkbox when pulling, on terminal use git pull --rebase). This will “rewrite your local history” so you are applying your changes on top of the latest version of the code (only use rebase when pulling; avoid rebasing one branch with another).

How to create a simple Top10 for your Unity game with Firebase

2015-05-22T21:00:00+00:00

You are finishing up your single-player game, already wrote the end screen… but something feels wrong. Something is missing. Your player has no idea how well he played, he sees his score but has no idea how other people finished.

Don’t worry! Having a Top 10 screen is quick and easy using Firebase. It’s a service that provides you with a JSON database - so you get no real processing online, and no way to have a “server” so to speak - but it has a free tier and data validation rules that should be enough for a simple game.

Start by creating an app in Firebase. When you are done, go to https://yourApp.firebaseio.com to enter the Forge. This articles assumes your database will have the following structure:

appName
  |- scores
    |- random ID
      |- cat
      |- name
      |- score
      |- time

The ID is auto-generated when data is posted to firebase and acts as a key - you could use a unique player ID for this. cat is a category, such as if the player died or finished the game, etc. time is an auto-generated value.

As security rules, use the following to make sure your data is validated to some extent and that no one can write on everything or otherwise mess with already existing content:

{
  "rules": {
    ".read": false,
    ".write": false,
    "scores": {
      ".read": true,
      ".indexOn": ["score"],
      "$score": {
        ".write": "!data.exists()",
        ".validate": "newData.hasChildren(['name', 'score', 'cat', 'time'])",
        "name": {
          ".validate": "newData.isString() &&
                        newData.val().length <= 30"
        },
        "score": {
          ".validate": "newData.isNumber()"
        },
        "cat": {
          ".validate": "newData.isString() &&
                        (newData.val() == 'death' 
                          || newData.val() == 'failure'
                          || newData.val() == 'success')"
        },
        "time": {
          ".validate": "newData.isNumber() &&
                        newData.val() <= now"
        }
      }
    }
  }
}

The score validation is also where you could do some sort of validation - something along the lines of && newData.val() <= yourMaximumScore.

And that’s it, you are done with the server side! For the client/game side, we will not use Firebase’s default client: it won’t work out of the box, specially if you are using the web player, so we’ll use UnityHTTP and the REST API. Just download the master revision and extract it somewhere in your project.

We’ll use two scenes. The first one shoud be your endgame scene - attach a script to an object, a button for example, with the following code that will upload the player’s score:

using UnityEngine;
using UnityEngine.UI;
using System.Collections;
using System;

public class EndGame: MonoBehaviour {

  public void BtnSendScore(string category) 
  {
    string playerName = //get your player name here
    if (playerName == null || string.IsNullOrEmpty (playerName.Trim())) 
    {
      playerName = "Some random player";
    }
    
    playerName = playerName.Trim();
    if(playerName.Length > 30) 
    {
      playerName = playerName.Substring(0, 30); 
    }
    int playerScore = //find your player score here

    SendScore (playerName, playerScore, category);
  }

  protected void SendScore(string name, int score, string category) 
  {
    Hashtable data = new Hashtable();
    data.Add ("name", name );
    data.Add ("score", score );
    data.Add ("cat", category);
    
    Hashtable time = new Hashtable ();
    time.Add (".sv", "timestamp");
    data.Add ("time", time);
    
    HTTP.Request theRequest = new HTTP.Request( "post", "https://yourApp.firebaseio.com/scores.json", data );
    theRequest.Send (( request ) => {
      Hashtable jsonObj = (Hashtable)JSON.JsonDecode(request.response.Text);
      if(jsonObj == null) 
      {
        Debug.LogError("server returned null or malformed response ):");
      }
      TopScores.SetPlayer ((string)jsonObj["name"], name, score, category);
      Application.LoadLevel(8); //fill with the correct ID for the next scene
    });
  }
}

Now create your Top10 scene. Start with a canvas and create an easy to use structure such as this:

Project structure (Unity)

On the screenshot, success, death and failure are category images that will be activated based on the returned content.

Attach a script to your Canvas with the following content:

using UnityEngine;
using UnityEngine.UI;
using System.Collections;
using System.Collections.Generic;
using System;

public class TopScores : MonoBehaviour {

  //this is set by EndGame and used to compare if the player is in the Top10 returned by the server, or otherwise add it as the 11th result
  public static Score player;

  public static void SetPlayer(string id, string name, int score, string category) 
  {
    player = new Score ();
    player.id = id;
    player.name = name;
    player.score = score;
    player.category = category;
    player.time = new DateTime ();
  }

  //Have a button point to this to exit
  public void Quit () 
  {
    Application.Quit ();
  }

  //you'll need to set this in unity as the parent 'Scores' object shown above
  public GameObject scorePanel;
  protected List<Score> scores = new List<Score>();
  protected void Start()
  {
    DownloadScores ();
  }

  protected void DownloadScores()
  {

    HTTP.Request someRequest = new HTTP.Request( "get", "https://yourApp.firebaseio.com/scores.json?orderBy="score"&limitToLast=10" );
    someRequest.Send( ( request ) => {
      Hashtable decoded = (Hashtable)JSON.JsonDecode(request.response.Text);
      if(decoded == null) 
      {
        Debug.LogError("server returned null or     malformed response ):");
        return;
      }

      foreach (DictionaryEntry json in decoded)
      {
        Hashtable jsonObj = (Hashtable)json.Value;
        Score s = new Score();
        s.id = (string)json.Key;
        s.name = (string)jsonObj["name"];
        s.score = (int)jsonObj["score"];
        s.category = (string)jsonObj["cat"];
        //gotta convert it!
        DateTime dtDateTime = new DateTime(1970, 1, 1, 0, 0, 0, 0, System.DateTimeKind.Utc);
        s.time = dtDateTime.AddMilliseconds( (long)jsonObj["time"] ).ToLocalTime();

        scores.Add(s);
      }
      AddScores();
    });
  }

  protected void AddScores()
  {
    //no dupes
    if (!scores.Contains (player)) 
    {
      scores.Add (player);
    }
    //firebase usually returns sorted content, but that's not guaranteed by the JSON format
    scores.Sort ((Score x, Score y) => { return x.score.CompareTo(y.score);});
            
    //we'll be filling top to bottom
    scores.Reverse();

    int i = 0;
    foreach(Score s in scores)
    {
      if(i>10)
      {
        break;
      }
      Transform panel = scorePanel.transform.Find("Panel " + i);
      panel.Find("score").GetComponent<Text>().text = s.score + "";
      panel.Find(s.category).gameObject.SetActive(true);
      panel.Find("name").GetComponent<Text>().text = s.name;
      if(!s.Equals(player)) 
      {
        //the player might not come from the server, so 'time' will be null
        panel.Find("time").GetComponent<Text>().text = s.time.ToString("yyyy-MM-dd");
      }
      i++;
    }
  }
  
  public class Score
  {
    public string id;
    public string name;
    public int score;
    public string category;
    public DateTime time;

    public override bool Equals(System.Object obj)
    {
      if (obj == null)
      {
        return false;
      }
      Score s = obj as Score;
      if ((System.Object)s == null)
      {
        return false;
      }
      return id == s.id;
    }
  }
}

And… done! Now you have a Top10 screen such as the one on the header of this post, from the game SCRUM’ed!

Grass performance on Unity5

2015-04-20T21:00:00+00:00

Last week when trying an alpha build of SCRUM’ed on the university lab something caught my attention: even in the lowest quality setting, where pretty much everything gpu intensive is disabled, the framerate was still at unaceptable levels (think 5~8FPS).

That is just… unacceptable. SCRUM’ed is an educational game that yes, approaches the Scrum metodology in a slightly different way, but is still meant to be played on an university lab where the computers are not quite last-gen.

After a bunch of debugging, the culpripts: grass and water4. Just removed the grass texture from the terrain and switched to WaterProDaytime to witness a ~100FPS increase in the lowest quality setting.

Now I’m not saying that SCRUM’ed is overly optimized - it certainly isn’t - but that’s quite a bottleneck, specially considering that only Standard Assets where used and the terrain is not particularly large.

Terrain setting used

I’ve read some suggestions to use meshes instead of the default grass painting, but to be honest that does not sound very practical. Just plain removing the grass is not the best solution either… It would be great if Unity implemented some sort of graceful degradation for grass and water based on the quality settings.

Docker and outgoing sockets on node.js

2015-02-12T21:00:00+00:00

Just a quick note: Docker’s networking works like a NAT ^{(more about that here)} for each container, effectively blocking incoming outside connections unless you expose the ports when running it.

That becomes a problem when you don’t know to which port someone’s going to be connecting to - say, when you are running an IRC bot and incoming connections happen at the same port you make an outgoing connection with, usually a random one at the 50000~65000 range.

You would usually solve that by making your container use the host’s network stack with the --net=\"host\" flag, which not only breaks proper containerization but also won’t work in tutum.

tutum support promissed support (see what I did there?) for passing flags in the future

From node.js v0.11.3 forward you can also fix that by specifying which local port you are going to use when creating a socket connection, like this ^(docs):

net.createConnection({
  host: 'irc.rizon.net', 
  port: 6667,
  localPort: 50555
});

Which results in 0.0.0.0:50555 ---> irc.rizon.net:6667, so you can expose the port in your Dockerfile and publish when setting up your container on tutum.

Deploy your Ghost blog using volumes in tutum

2015-02-05T21:00:00+00:00

So far we’ve been running our containers from the command line - it works fine, but you have to SSH and do your complicated stuff there… we can make it better! Tutum is a service I’ve been following for a while, and they recently introduced a much antecipated feature: they now support volumes.

If you’ve forgotten, volumes are directories shared with the host outside of the container’s filesystem - that is, volumes are not subject to the container usual versioning and persist when the container is terminated (but not when it’s removed). They can also be shared between multiple containers, which make them ideal for data persistence. You can find more about containers here.

Think of tutum as your own personal Docker cloud: you can manage machines from DigitalOcean, Amazon Web Services, Microsoft Azure, and pretty much any Ubuntu machine you have root access to. It adds a lot to your Docker workflow - you get autoscaling, easier server management, auto restarts on fail, automatic deployment… and the best of all: integration with Docker’s Registry, so when you commit code changes to your Git repository the image can be automatically rebuilt and deployed!

In my case I want full control of the host machine (with SSH access), so I’ll start with a basic Ubuntu 14.10 image from DigitalOcean and install tutum’s daemon there. You can, of course, just have tutum automatically create nodes for you on demand and enjoy the easy scaling.

Don’t forget to add your SSH keys when creating the droplet!

After logging in to your new server, go to your tutum dashboard and click ‘Bring your own node’. This will give you a curl command to run, which will install the agent that makes all the magic possible.

If you run docker ps right after the node has been deployed in tutum, you’ll see a bunch of tutum/* containers running. Those are necessary to provide the cools stuff like resource monitoring for each node, which you can see in the dashboard.

From there, we can create our first service. We’ll start by using dockerfile/ubuntu to create our data-only container and a data volume: Choose “Create your first service”, search for the image on the available public images. Call it “data-container”. You don’t need to set any of the advanced options or the environment variables, but do set /data as a container path and /docker/data as a host path on the volumes config.

Remember to create the folder /docker/data on your host first!

Create the service and start it - it will be deployed and then shown as ‘running’, after which you can stop it (do not remove it or you’ll lose your volume if no other container is using it!).

We can now deploy Ghost, our blogging platform. We’ll use the dockerfile/ghost image, call it ‘ghost’, set it to auto restart, and on the volumes configuration “add volumes from” our data-container service. We’ll also add /docker/blog from the host as /ghost-override, which contains our custom themes and configuration files.

Make sure your /docker/blog folder actually exists on the host, create and deploy the service.

Next we’ll run a nginx proxy to our blog, using dockerfile/nginx. Create a new service, mark port 80 as published to host port 80 (also do it with port 443 if you are using https), link it to your Ghost service, and add /docker/nginx/sites-enabled from your host to /etc/nginx/sites-enabled in your container.

You can leverage the host file to write your sites-enabled config:

server {
  listen             80;
  server_name        blog.marcelofs.com;
  location / {
    proxy_pass       http://ghost:2368;
  }
}

Want nginx to cache your Ghost blog? Start here.

We can then migrate our old data to the new blog, by copying /docker/data/blog.db to the new host and redeploying the Ghost service. Do notice that this will redeploy the nginx service as well, because of the link between the containers.

And there you go, simple as pie! tutum will also provide you with a custom view of cAdvisor that will let you keep an eye on resource usage for both the host and each running container.